KR101963466B1 - Ｍ2ｍ(ｍａｃｈｉｎｅ-ｔｏ-ｍａｃｈｉｎｅ) 엔터티를 관리하는 시스템, 방법 및 장치 - Google Patents

Ｍ2ｍ(ｍａｃｈｉｎｅ-ｔｏ-ｍａｃｈｉｎｅ) 엔터티를 관리하는 시스템, 방법 및 장치 Download PDF

Info

Publication number
KR101963466B1
KR101963466B1 KR1020137024052A KR20137024052A KR101963466B1 KR 101963466 B1 KR101963466 B1 KR 101963466B1 KR 1020137024052 A KR1020137024052 A KR 1020137024052A KR 20137024052 A KR20137024052 A KR 20137024052A KR 101963466 B1 KR101963466 B1 KR 101963466B1
Authority
KR
South Korea
Prior art keywords
server
resource
command
resource structure
sub
Prior art date
Application number
KR1020137024052A
Other languages
English (en)
Other versions
KR20140008373A (ko
Inventor
총강 왕
주니어 폴 엘 러셀
광 루
데일 엔 시드
리준 동
마이클 에프 스타씨닉
Original Assignee
아이오티 홀딩스, 인크.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 아이오티 홀딩스, 인크. filed Critical 아이오티 홀딩스, 인크.
Publication of KR20140008373A publication Critical patent/KR20140008373A/ko
Application granted granted Critical
Publication of KR101963466B1 publication Critical patent/KR101963466B1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H04L67/125—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks involving control of end-device applications over a network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02—Standardisation; Integration
    • H04L41/0213—Standardised network management protocols, e.g. simple network management protocol [SNMP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02—Standardisation; Integration
    • H04L41/0233—Object-oriented techniques, for representation of network management data, e.g. common object request broker architecture [CORBA]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02—Standardisation; Integration
    • H04L41/0246—Exchanging or transporting network management information using the Internet; Embedding network management web servers in network elements; Web-services-based protocols
    • H04L41/0273—Exchanging or transporting network management information using the Internet; Embedding network management web servers in network elements; Web-services-based protocols using web services for network management, e.g. simple object access protocol [SOAP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0806—Configuration setting for initial configuration or provisioning, e.g. plug-and-play
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/50—Service provisioning or reconfiguring
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/60—Subscription-based services using application servers or record carriers, e.g. SIM application toolkits
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02—Services making use of location information
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y04—INFORMATION OR COMMUNICATION TECHNOLOGIES HAVING AN IMPACT ON OTHER TECHNOLOGY AREAS
    • Y04S—SYSTEMS INTEGRATING TECHNOLOGIES RELATED TO POWER NETWORK OPERATION, COMMUNICATION OR INFORMATION TECHNOLOGIES FOR IMPROVING THE ELECTRICAL POWER GENERATION, TRANSMISSION, DISTRIBUTION, MANAGEMENT OR USAGE, i.e. SMART GRIDS
    • Y04S40/00—Systems for electrical power generation, transmission, distribution or end-user application management characterised by the use of communication or information technologies, or communication or information technology specific aspects supporting them
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y04—INFORMATION OR COMMUNICATION TECHNOLOGIES HAVING AN IMPACT ON OTHER TECHNOLOGY AREAS
    • Y04S—SYSTEMS INTEGRATING TECHNOLOGIES RELATED TO POWER NETWORK OPERATION, COMMUNICATION OR INFORMATION TECHNOLOGIES FOR IMPROVING THE ELECTRICAL POWER GENERATION, TRANSMISSION, DISTRIBUTION, MANAGEMENT OR USAGE, i.e. SMART GRIDS
    • Y04S40/00—Systems for electrical power generation, transmission, distribution or end-user application management characterised by the use of communication or information technologies, or communication or information technology specific aspects supporting them
    • Y04S40/18—Network protocols supporting networked applications, e.g. including control of end-device applications over a network

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Multimedia (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

M2M(machine-to-machine) 엔터티를 관리하는 시스템, 방법 및 장치가 개시되어 있다. 본 명세서에는 M2M 환경에서 M2M 엔터티를 관리하는 하나 이상의 관리 계층을 구현하는 단계를 포함할 수 있는 방법이 포함되어 있다. 이 방법은 또한 복수의 관리 계층을 사용하여 M2M 영역 네트워크(M2M area network)를 관리하는 단계를 포함할 수 있고, 여기서 M2M 영역 네트워크는 하나 이상의 M2M 종단 디바이스(M2M end device)를 포함할 수 있다. M2M 종단 디바이스는, 예를 들어, M2M 게이트웨이 및/또는 M2M 디바이스를 포함할 수 있다. 관리 계층은 응용 프로그램 관리 계층, 서비스 관리 계층, 네트워크 관리 계층 및 디바이스 관리 계층 중 임의의 것을 포함할 수 있다. 관리 계층은 M2M 엔터티의 구성 관리, 장애 관리, 및 성능 관리 중 임의의 것을 제공할 수 있다.

Description

Ｍ2Ｍ(ＭＡＣＨＩＮＥ-ＴＯ-ＭＡＣＨＩＮＥ) 엔터티를 관리하는 시스템, 방법 및 장치{SYSTEMS, METHODS AND APPARATUS FOR MANAGING MACHINE-TO-MACHINE (M2M) ENTITIES}
관련 출원의 상호 참조
이 출원은 (i) 2011년 2월 11일자로 출원된, 발명의 명칭이 "향상된 게이트웨이-기반 M2M(Machine-To-Machine) 디바이스 관리(Enhanced Gateway-Based Machine-To-Machine (M2M) Device Management)"인 미국 가특허 출원 제61/441,911호(대리인 참조 번호 IDC-10928US01); (ii) 2011년 6월 14일자로 출원된, 발명의 명칭이 "M2M 영역 네트워크 및 M2M 게이트웨이 배후에 있는 M2M 디바이스를 관리하는 데이터 모델(Data Model For Managing M2M Area Networks and M2M Devices behind the M2M Gateway)"인 미국 가특허 출원 제61/496,812호(대리인 참조 번호 IDC-11072US01); (iii) 2011년 6월 24일자로 출원된, 발명의 명칭이 "M2M 영역 네트워크 및 M2M 게이트웨이 배후에 있는 M2M 디바이스를 관리하는 데이터 모델(Data Model For Managing M2M Area Networks and M2M Devices behind the M2M Gateway)"인 미국 가특허 출원 제61/500,798호(대리인 참조 번호 IDC-11077US01); (iv) 2011년 2월 18일자로 출원된, 발명의 명칭이 "M2M(Machine-To-Machine) 원격 엔터티 관리(Machine-To-Machine (M2M) Remote Entity Management)"인 미국 가특허 출원 제61/444,323호(대리인 참조 번호 IDC-10930US01); (v) 2011년 3월 14일자로 출원된, 발명의 명칭이 "M2M(Machine-To-Machine) 원격 엔터티 관리(Machine-To-Machine (M2M) Remote Entity Management)"인 미국 가특허 출원 제IDC-10954US01호(대리인 참조 번호 IDC-10954US01); (vi) 2011년 3월 13일자로 출원된, 발명의 명칭이 "M2M(Machine-To-Machine) 통신을 위한 원격 엔터티 관리(Remote Entity Management for Machine-to-Machine (M2M) Communications)"인 미국 가특허 출원 제61/485,631호(대리인 참조 번호 IDC-11047US01); (vii) 2011년 6월 24일자로 출원된, 발명의 명칭이 "M2M(Machine-To-Machine) 통신을 위한 원격 엔터티 관리(Remote Entity Management for Machine-to-Machine (M2M) Communications)"인 미국 가특허 출원 제61/501,046호(대리인 참조 번호 IDC-11078US01); 및 (viii) 2011년 7월 15일자로 출원된, 발명의 명칭이 "M2M(Machine-To-Machine) 통신을 위한 원격 엔터티 관리(Remote Entity Management for Machine-to-Machine (M2M) Communications)"인 미국 가특허 출원 제61/508,564호(대리인 참조 번호 IDC-11098US01)에 관련되어 있으며 이들을 기초로 우선권을 주장한다. 앞서 언급한 미국 가특허 출원들 각각은 참조 문헌으로서 본 명세서에 포함된다.
본 출원은 통신에 관한 것으로서, 상세하게는 "M2M"(machine-to-machine) 통신에 관한 것이다.
M2M(machine-to-machine) 통신은, 이러한 M2M 통신을 통해, 스마트 계량(smart metering), 홈 오토메이션(home automation), eHealth 및 차량 관리(fleet management) 등의 다양한 응용 프로그램("M2M 응용 프로그램(M2M application)")을 수행하기 위한 정보를 송신, 수신 또는 교환하도록 구성되어 있는 디바이스(머신이라고 함)에 의해 및/또는 그들 사이에서 수행되는 통신 카테고리를 말한다. 일반적으로, 다양한 응용 프로그램의 실행 및 차례로 이러한 실행에 부속된 M2M 통신은 M2M 통신의 트리거링, 개시 및/또는 발신을 위해 사람의 개입을 필요로 하지 않고 머신에 의해 수행된다. 잘 알 것인 바와 같이, M2M 응용 프로그램의 성공적인 구현 및 배포는 다양한 엔터티에 의해 제조되고 운용될 수 있는 다양한 머신들 간의 상호 운용성을 보장해주는(예컨대, 보장해주기 위한 요건을 정의하는) 산업 전반에 걸친 표준의 채택에 의존할 가능성이 많다.
M2M(machine-to-machine) 엔터티를 관리하는 시스템, 방법 및 장치가 개시되어 있다. 본 명세서에는 M2M 환경에서 M2M 엔터티를 관리하는 하나 이상의 관리 계층을 구현하는 단계를 포함할 수 있는 방법이 포함되어 있다. 이 방법은 또한 복수의 관리 계층을 사용하여 M2M 영역 네트워크(M2M area network)를 관리하는 단계를 포함할 수 있고, 여기서 M2M 영역 네트워크는 하나 이상의 M2M 종단 디바이스(M2M end device)를 포함할 수 있다. M2M 종단 디바이스는, 예를 들어, M2M 게이트웨이 및/또는 M2M 디바이스를 포함할 수 있다. 관리 계층은 응용 프로그램 관리 계층, 서비스 관리 계층, 네트워크 관리 계층 및 디바이스 관리 계층 중 임의의 것을 포함할 수 있다. 관리 계층은 M2M 엔터티의 구성 관리, 장애 관리, 및 성능 관리 중 임의의 것을 제공할 수 있다.
일례로서 본 명세서에 첨부된 도면과 관련하여 주어진 이하의 상세한 설명으로부터 보다 상세하게 이해될 수 있다. 이러한 첨부 도면 내의 도면들은, 상세한 설명과 같이, 예이다. 그에 따라, 도면 및 상세한 설명은 제한하는 것으로 생각되어서는 안되며, 다른 똑같이 효과적인 예가 가능하고 있을 수 있다. 게다가, 도면에서 유사한 참조 번호는 유사한 요소를 나타낸다.
도 1a 내지 도 1c는 M2M(machine-to-machine) 통신 및/또는 동작에 관한 실시예를 비롯한 하나 이상의 실시예가 구현되거나 다른 방식으로 수행될 수 있는 시스템의 한 예를 나타낸 블록도.
도 2는 원격 엔터티 관리(remote entity management, "REM")를 수행하는 기능적 아키텍처를 정의하는 논리 관리 계층들의 예시적인 세트를 나타낸 블록도.
도 3a는 한 세트의 관리 계층 및 그의 기능에 따라 리소스 구조체로 SCL을 프로비저닝하는 예시적인 리소스 구조체 프레임워크를 나타낸 블록도.
도 3b는 한 세트의 관리 계층 및 그의 기능에 따라 리소스 구조체로 SCL을 프로비저닝하는 예시적인 리소스 구조체 프레임워크를 나타낸 블록도.
도 3c는 한 세트의 관리 계층 및 그의 기능에 따라 리소스 구조체로 SCL을 프로비저닝하는 예시적인 리소스 구조체 프레임워크를 나타낸 블록도.
도 4a는 관리 객체("mgmtObjs") 리소스로 SCL을 프로비저닝하는 예시적인 리소스 구조체 프레임워크를 나타낸 블록도.
도 4b는 관리 객체("mgmtObjs") 리소스로 SCL을 프로비저닝하는 예시적인 리소스 구조체 프레임워크를 나타낸 블록도.
도 5는 xREM을 수행하는 클라이언트-서버 모델의 다이어그램을 나타낸 블록도.
도 6은 다수의 상이한 관리 프로토콜을 사용하여 xREM을 지원하는 터널-기반 방식을 나타낸 블록도.
도 7a 내지 도 7c는, 각각, REM을 위해 사용할 관리 프로토콜의 유형을 결정하는 예시적인 흐름(700, 730 및 760)을 나타낸 흐름도.
도 8은 xREM을 위한 관리 프로토콜의 유형을 협상하고 및/또는 디바이스에 알려주는 절차를 나타낸 메시지 흐름도.
도 9는 xREM을 위한 관리 프로토콜의 유형을 협상하고 및/또는 디바이스에 알려주는 절차를 나타낸 메시지 흐름도.
도 10은 xREM을 위한 관리 프로토콜의 유형을 협상하고 및/또는 디바이스에 알려주는 절차를 나타낸 메시지 흐름도.
도 11은 xREM을 위한 관리 프로토콜의 유형을 협상하고 및/또는 디바이스에 알려주는 절차를 나타낸 메시지 흐름도.
도 12는 리소스 accessHistories의 예시적인 구조체를 나타낸 도면.
도 13은 "method"에 기초하여 구성된 리소스 accessHistories에 대한 예시적인 구조체를 나타낸 도면.
도 14는 "method" 및 "requestorID"에 기초하여 구성된 리소스 accessHistories에 대한 예시적인 구조체를 나타낸 도면.
도 15는 관리 권한 위임(위임자에 의해 개시됨)을 위한 절차의 메시지 흐름도.
도 16은 관리 권한 위임(디바이스에 의해 개시됨)을 위한 예시적인 메시지 흐름도.
도 17은 관리 권한 위임(수증자에게 직접, 디바이스에 의해 개시됨)을 위한 예시적인 메시지 흐름도.
도 18은 관리 권한 위임(수증자에 의해 개시됨)을 위한 예시적인 메시지 흐름도.
도 19는 관리 권한 위임(게이트웨이가 프록시 역할을 함)을 위한 예시적인 메시지 흐름도.
도 20은 관리 권한 위임(디바이스와 게이트웨이 간의 위임)을 위한 예시적인 메시지 흐름도.
도 21은 관리 권한 위임에 대한 예시적인 절차를 나타낸 도면.
도 22a 내지 도 22c는 리소스 command의 예시적인 구조체를 나타낸 블록도.
도 23은 리소스 command에 대한 예시적인 구조체를 나타낸 블록도.
도 24a 및 도 24b는 리소스 command에 대한 예시적인 구조체를 나타낸 블록도.
도 25a 및 도 25b는 리소스 commands에 대한 예시적인 구조체를 나타낸 블록도.
도 26a 및 도 26b는 리소스 commands에 대한 예시적인 구조체를 나타낸 블록도.
도 27a 및 도 27b는 리소스 commands에 대한 예시적인 구조체를 나타낸 블록도.
도 28a 및 도 28b는 리소스 command의 예시적인 구조체를 나타낸 블록도.
도 28c 및 도 28d는 리소스 command 인스턴스의 예시적인 구조체를 나타낸 블록도.
도 29a 내지 도 29r은 리소스 commands의 xREM을 위한 예시적인 메시지 흐름을 나타낸 메시지 흐름도.
도 30a는 OMA GwMO "투명" 모드를 이용함으로써 M2M GW(G')를 통해 D-유형 ETSI M2M 디바이스를 관리하는 예시적인 아키텍처를 나타낸 블록도.
도 30b는 ETSI M2M xREM의 예시적인 아키텍처를 나타낸 블록도.
도 31a는 OMA GwMO1.0을 이용하는 예시적인 아키텍처를 나타낸 블록도.
도 31b는 xREM의 예시적인 아키텍처를 나타낸 블록도.
도 32a는 OMA GwMO1.0을 이용하는 예시적인 아키텍처를 나타낸 블록도.
도 32b는 ETSI M2M xREM의 예시적인 아키텍처를 나타낸 블록도.
도 33a는 OMA GwMO1.0을 이용하는 예시적인 아키텍처를 나타낸 블록도.
도 33b는 본 개시 내용의 실시예에 따른, ETSI M2M xREM의 예시적인 아키텍처를 나타낸 블록도.
도 34는 OMA GwMO를 이용하는 GW-기반 디바이스 관리의 한 예를 나타낸 블록도.
도 35는 OMA DM과 M2M GW의 부분적으로 엄격한 통합(partially tight integration)을 위한 예시적인 아키텍처를 나타낸 블록도.
도 36은 OMA DM과 M2M GW의 느슨한 통합(loose integration)을 위한 예시적인 아키텍처를 나타낸 블록도.
도 37은 etsiAreaNwkInfo의 예시적인 리소스 구조체를 나타낸 블록도.
도 38a는 areaNwkInstance의 예시적인 리소스 구조체를 나타낸 블록도.
도 38b는 도 38a의 areaNwkInstance의 6LoWPAN에 대한 서브리소스 설명의 예시적인 리소스 구조체를 나타낸 블록도.
도 38c는 areaNwkInstance의 예시적인 리소스 구조체를 나타낸 블록도.
도 39는 etsiAreaNwkDeviceInventory의 예시적인 리소스 구조체를 나타낸 블록도.
도 40a는 deviceInstance의 예시적인 리소스 구조체를 나타낸 블록도.
도 40b는 deviceInstance의 예시적인 리소스 구조체를 나타낸 블록도.
도 41a는 etsiAreaNwkDeviceGroup의 예시적인 리소스 구조체를 나타낸 블록도.
도 41b는 etsiAreaNwkDeviceGroup의 예시적인 리소스 구조체를 나타낸 블록도.
도 42는 deviceGroupInstance의 예시적인 리소스 구조체를 나타낸 블록도.
도 43a는 etsiGroupMgmtOperations의 예시적인 리소스 구조체를 나타낸 블록도.
도 43b는 etsiareaNwkGroupOperations의 예시적인 리소스 구조체를 나타낸 블록도.
도 44a는 operationInstance의 예시적인 리소스 구조체를 나타낸 블록도.
도 44b는 operationInstance의 예시적인 리소스 구조체를 나타낸 블록도.
도 45는 etsiSensor의 예시적인 리소스 구조체를 나타낸 블록도.
도 46은 sensorInstance의 예시적인 리소스 구조체를 나타낸 블록도.
도 47은 xREM을 수행하는 시스템의 예시적인 아키텍처의 블록도.
도 48a는 하나 이상의 개시된 실시예가 구현될 수 있는 예시적인 통신 시스템을 나타낸 도면.
도 48b는 도 48a에 예시된 통신 시스템 내에서 사용될 수 있는 예시적인 WTRU(wireless transmit/receive unit)의 시스템도.
도 48c는 도 48a에 예시된 통신 시스템 내에서 사용될 수 있는 예시적인 무선 액세스 네트워크 및 예시적인 코어 네트워크의 시스템도.
도 48d는 도 48a에 예시된 통신 시스템 내에서 사용될 수 있는 다른 예시적인 무선 액세스 네트워크 및 예시적인 코어 네트워크의 시스템도.
도 48e는 도 48a에 예시된 통신 시스템 내에서 사용될 수 있는 다른 예시적인 무선 액세스 네트워크 및 예시적인 코어 네트워크의 시스템도.
예시적인 시스템 아키텍처
도 1a 내지 도 1c는 하나 이상의 실시예가 구현되거나 다른 방식으로 수행될 수 있는 시스템(10)의 한 예를 나타낸 블록도이다. 이러한 실시예는, 예를 들어, M2M(Machine-To-Machine) 통신 및/또는 운용 - M2M 응용 프로그램, M2M 서비스 능력("SC"), M2M 영역 네트워크, M2M 게이트웨이 및 M2M 디바이스 등의 M2M 원격 엔터티를 관리하는 것을 포함함 - 에 관한 실시예를 포함할 수 있다.
시스템(10)은 하나 이상의 아키텍처에 따라 구성되고 및/또는 그를 사용하여 구현될 수 있고; 이들 아키텍처 중 임의의 것은 다양한 표준에 기초하고 및/또는 그에 따라 구성될 수 있다. 이들 표준은, 예를 들어, "Machine-to-Machine (M2M) Communications; Functional Architecture"라는 제하의 유럽 전기 통신 표준 협회((European Telecommunications Standards Institute, "ETSI")에 의해 발표된 기술 규격 초안(draft technical specification)("TS") ("ETSI TS 102 690"라고 함) 등의 M2M 통신 및/또는 운용에 관련된 것들을 포함할 수 있다. 다른 예는, 예를 들어, "Technical Specification Group Services and System Aspects; Service requirements for Machine-Type Communications (MTC)"라는 제하의 3GPP TS 22.368 등의 "MTC"(Machine-Type Communications)에 관한 것을 비롯한, "3GPP"(3rd Generation Partnership Project) 및/또는 "3GPP2"(3rd Generation Partnership Project 2)에 의해 발표된 표준을 포함할 수 있다. ETSI TS 102 690 및 3 GPP TS 22.368 둘 다는 참조 문헌으로서 본 명세서에 포함된다. 시스템(10)의 아키텍처(들)는 다른 표준을 따를 수도 있다.
시스템(10)은 디바이스 영역(12), 네트워크 영역(14) 및 네트워크 응용 프로그램 영역(16)을 포함할 수 있다. 네트워크 응용 프로그램 영역(16)은 M2M 네트워크 응용 프로그램(18a, 18b)을 포함할 수 있다. 이들 M2M 네트워크 응용 프로그램(18a, 18b)은 각자의 호스트 디바이스(도시 생략) 상에서 저장, 실행 및/또는 호스팅될 수 있다. 다른 대안으로서, M2M 네트워크 응용 프로그램(18a, 18b)은 동일한 호스트 디바이스(역시 도시 생략) 상에서 저장, 실행 및/또는 호스팅될 수 있다. 호스트 디바이스(들)는, 예를 들어, 호스트-응용 프로그램 서버를 비롯한 하나 이상의 서버를 포함할 수 있고, 임의의 적당한 운영 체제 상에서 동작하고 소프트웨어를 실행할 수 있는 하나 이상의 범용 또는 특수 목적 컴퓨터, 개인용 컴퓨터, 메인프레임, 미니컴퓨터, 서버형 컴퓨터 및/또는 임의의 프로세서-기반 플랫폼에 설치되어 있을 수 있다. 호스트 디바이스(들)는 하나의 통합형 디바이스(unitary device)에 형성되고 하나의 노드(서비스 제공 노드, 클라이언트 노드, 피어 노드 또는 기타) 상에 집중되어 있을 수 있는 다수의 요소를 포함할 수 있다. 다른 대안으로서, 호스트 디바이스(들)의 요소는 2개 이상의 개별 디바이스로 형성될 수 있고, 그에 따라, 복수의 노드(서비스 제공 노드, 클라이언트 노드, 피어 노드 또는 기타) 간에 분산되어 있을 수 있다.
네트워크 영역(14)은 액세스 및/또는 코어("액세스/코어") 네트워크(20) 및 전송 네트워크(22)를 포함할 수 있다. 액세스/코어 네트워크(22)는, 예를 들어, (i) 디지털 가입자 회선 기술(모두 합하여 "xDSL"), (ii) "HFC"(hybrid-fiber-coax) 네트워크, (iii) "PLC"(programmable logic controller), (iv) 위성 통신 및 네트워크, (v) "GERAN"["GSM"(Global System for Mobile telecommunication)/"EDGE"(Enhanced Data GSM Environment) radio access network], (vi) "UTRAN"["UMTS"(Universal Mobile Telecommunication System) Terrestrial Radio Access Network], (vii) "eUTRAN"(evolved UTRAN), (viii) "WLAN"(wireless local area network), "WiMAX"(Worldwide Interoperability for Microwave Access) 등에 대한 하나 이상의 프로토콜에 따라 통신하도록 구성되어 있는 네트워크일 수 있다. 액세스 및/또는 코어 네트워크(20)를 나타낼 수 있는 예시적인 액세스 및/또는 코어 네트워크의 상세는, 도 48a 내지 도 48e와 관련하여 이하에 기술되어 있다. 전송 네트워크(22)를 나타낼 수 있는 예시적인 전송 네트워크의 상세도 역시, 도 48a 내지 도 48e와 관련하여 이하에 기술되어 있다.
액세스/코어 네트워크(20)는 또한 인터넷 프로토콜("IP") 군(suite)에 따라 연결을 제공할 수 있다. 액세스/코어 네트워크(20)는 다른 통신 프로토콜에 따라 연결을 제공할 수도 있다. 그에 부가하여, 액세스/코어 네트워크(20)는 서비스 및 네트워크 제어 기능, 다른 네트워크와의 상호 연결, 및 로밍 서비스를 제공할 수 있다. 예로서, 액세스/코어 네트워크(20)는 3GPP, ETSI "TISPAN"(Telecommunications and Internet converged Services and Protocols for Advanced Networking)에 의해 발표된 프로토콜 및 3GPP2에 의해 발표된 프로토콜에 따라 통신하도록 구성되어 있는 네트워크일 수 있다.
액세스/코어 네트워크(20)는 M2M 서버(24a)를 포함할 수 있고, 전송 네트워크(22)는 M2M 서버(24b, 24c)를 포함할 수 있다. 각각의 M2M 서버(24a 내지 24c)는 각자의 서비스 제공자에 의해 소유, 유지 및/또는 운용될 수 있다. 예를 들어, M2M 서버(24a)는 무선(예컨대, 셀룰러) 통신 서비스 제공자에 의해 소유, 유지 및/또는 운용될 수 있는 반면, M2M 서버(24b, 24c)는 다른 서비스 제공자에 의해 소유, 유지 및/또는 운용될 수 있다. 어떤 경우에, 각각의 제1, 제2 및 제3 M2M 서버(24a 내지 24c)의 소유권, 유지 보수 및/또는 운용이 2개 이상의 제공자 간에 분할되어 있을 수 있다.
M2M 서버(24a 내지 24c)는 각자의 네트워크 서비스 능력 계층(network service capability layer, "N-SCL")(26a 내지 26c) 및 각자의 네트워크 통신 프로토콜 스택(28a 내지 28c)을 포함하거나 포함하도록 구성되어 있을 수 있다(도 1b). N-SCL(26a 내지 26c)은 각자의 M2M SC("N-SCs")(30a 내지 30c) 및 부속 리소스 구조체(32a 내지 32c)를 포함할 수 있다(도 1b).
디바이스 영역(12)은 M2M 디바이스(34a 내지 34g), M2M 게이트웨이(36a, 36b), 및 M2M 영역 네트워크(38a, 38b)를 포함할 수 있다. M2M 디바이스(34a 내지 34g)는 각자의 M2M 응용 프로그램("DA")(40a 내지 40h) 및 각자의 네트워크 통신 프로토콜 스택(42a 내지 42g)을 포함할 수 있다. M2M 디바이스(34a 내지 34g), 즉 M2M 디바이스(34a 내지 34d)[이후부터 "D(34a 내지 34d)" 또는 "D-유형 디바이스(34a 내지 34d)"라고 함]는 각자의 SCL("D-SCL")(44a 내지 44d)을 포함할 수 있다. D-SCL(44a 내지 44d)은 각자의 SC("D-SC")(46a 내지 46d) 및 부속 리소스 구조체(48a 내지 48d)를 포함하거나 포함하도록 구성되어 있을 수 있다(도 1b).
M2M 디바이스(34e 내지 34g)[이후부터 "D'(34e 내지 34g)" 또는 "D'-유형 디바이스(34e 내지 34g)"라고 함]는 D-SCL을 가지고 있지 않다. D(34a 내지 34d)는 다른 점에서도 D'(34e 내지 34g)과 상이할 수 있다. 예를 들어, D'(34e 내지 34f)은 처리 능력 및 메모리 제한 등의 리소스 제약조건에 속박되어 있을 수 있는 반면, D(34a 내지 34d)는 이러한 리소스 제약조건에 속박되어 있지 않을 수 있다. 다른 대안으로서 및/또는 그에 부가하여, D'(34e 내지 34g)은 D-SCL(44a 내지 44d)와 상이한 기능을 포함하거나 포함하도록 구성되어 있을 수 있다.
M2M 게이트웨이(36a, 36b)는 각자의 M2M 응용 프로그램("GA")(50a, 50b), 각자의 네트워크 통신 프로토콜 스택(52a, 52b) 및 각자의 SCL("G-SCL")(54a, 54b)을 포함하거나 포함하도록 구성되어 있을 수 있다(도 1). G-SCL(54a, 54b)은 각자의 SC("G-SC")(56a, 56b) 및 부속 리소스 구조체(58a 내지 58e)를 포함하거나 포함하도록 구성되어 있을 수 있다(도 1b).
M2M 영역 네트워크(38a, 38b)는 M2M 게이트웨이(36a, 36b) 및 다른 M2M 게이트웨이(도시 생략)(있는 경우)에 통신 연결되어 있을 수 있다. M2M 영역 네트워크(38a, 38b)는, D(34d) 및 D'(34e 내지 34g)에 부가하여, M2M 디바이스(도시 생략)를 포함할 수 있다. 이들 부가의 M2M 디바이스는 D-유형 또는 D'-유형 디바이스일 수 있다. 각각의 M2M 영역 네트워크(38a, 38b)는, 예를 들어, 메쉬 및/또는 피어-투-피어 아키텍처를 사용하여 구성될 수 있다.
D(34a) 및 D'(34e)을 서로 통신 연결시키고 및/또는 D(34d), D'(34e) 및/또는 M2M 영역 네트워크(38a)의 이웃하는 M2M 디바이스 간에 통신 연결시키는 통신 링크는 유선 및/또는 무선일 수 있다. D'(34f) 및 D'(34g)을 서로 통신 연결시키고 및/또는 D'(34f), D'(34g) 및/또는 M2M 영역 네트워크(38b)의 이웃하는 M2M 디바이스 간에 통신 연결시키는 통신 링크도 역시 유선 및/또는 무선일 수 있다.
D(34d), D'(34e) 및 M2M 영역 네트워크(38a)의 다른 M2M 디바이스를 M2M 게이트웨이(36a)에 통신 연결시키는 통신 링크는, D'(34f, 34g) 및 M2M 영역 네트워크(38b)의 다른 M2M 디바이스를 M2M 게이트웨이(36b)에 통신 연결시키는 통신 링크와 함께, 유선 및/또는 무선일 수 있다. 이들 통신 링크 각각은 독점 인터페이스, 표준 인터페이스 및/또는 공개 인터페이스에 따라 정의될 수 있다. 다른 대안으로서, 통신 링크는, 예를 들어, dIa 기준점 등의 기준점으로서 정의될 수 있다. 이러한 dIa 기준점을 나타낼 수 있는 예시적인 dIa 기준점에 대한 상세는 ETSI TS 102 690에서 찾아볼 수 있다.
M2M 게이트웨이(36a), M2M 게이트웨이(36b) 및 D(34b 및 34c) 그리고 D(34a)는, 각각, 유선 및/또는 무선 통신 링크를 통해 M2M 서버(24a, 24b 및 24c)에 통신 연결되어 있을 수 있다. 이들 통신 링크는 독점 인터페이스, 표준 인터페이스 및/또는 공개 인터페이스에 따라 정의될 수 있다. 다른 대안으로서, 통신 링크는, 예를 들어, mIa 기준점 등의 기준점으로서 정의될 수 있다. 이러한 mIa 기준점을 나타낼 수 있는 예시적인 mIa 기준점에 대한 상세는 ETSI TS 102 690에서 찾아볼 수 있다.
M2M 네트워크 응용 프로그램(18a)을 M2M 서버(24a)와 통신 연결시키고 M2M 네트워크 응용 프로그램(18b)을 M2M 서버(24b, 24c)와 통신 연결시키는 통신 링크는 유선 및/또는 무선일 수 있다. 이들 통신 링크 각각은 독점 인터페이스, 표준 인터페이스 및/또는 공개 인터페이스에 따라 정의될 수 있다. 다른 대안으로서, 통신 링크는, 예를 들어, mIa 기준점 등의 기준점으로서 정의될 수 있다. 이러한 mIa 기준점을 나타낼 수 있는 예시적인 mIa 기준점에 대한 상세는 ETSI TS 102 690에서 찾아볼 수 있다.
D(34a 내지 34d)의 DA(각각, 40a 내지 40d)와 D-SCL(각각, 44a 내지 44d) 사이의 통신은 mIa 기준점을 사용하여 수행될 수 있다. dIa 및 mIa 기준점은 M2M 네트워크 응용 프로그램(18b)과 DA(40a 내지 40e) 사이에 및 M2M 네트워크 응용 프로그램(18a)과 DA(40f 및 40g) 사이에 균일한 인터페이스를 제공할 수 있다.
2개의 M2M 게이트웨이 및 8개의 M2M 디바이스가 도 1에 도시되어 있지만, 디바이스 영역(12)은 더 많거나 더 적은 M2M 게이트웨이 및 더 많거나 더 적은 M2M 디바이스를 포함할 수 있다. 실제로, 디바이스 영역(12)은 많은 M2M 디바이스 및 많은 M2M 게이트웨이를 가질 가능성이 있다. 그에 부가하여 및/또는 다른 대안으로서, 시스템(10)은 더 많거나 더 적은 M2M 서버, 더 많거나 더 적은 M2M 네트워크 응용 프로그램 및 더 많거나 더 적은 M2M 영역 네트워크를 포함할 수 있다.
각각의 M2M 영역 네트워크(38a, 38b)는, 예를 들어, "IEEE"(Institute of Institute of Electrical and Electronics Engineers) 802.15.x, Zigbee, Bluetooth, "IETF"(Internet Engineering Task Force) "ROLL"(Routing Over Low power and Lossy network), 산업 자동화를 위한 "ISA"(International Society of Automation) 무선 시스템: 프로세스 제어 및 관련 응용("ISA100.11a") 등과 같은 개인 영역 네트워크 프로토콜에 따라 통신하도록 구성되어 있는 네트워크일 수 있다. M2M 영역 네트워크(38a, 38b)는, 예를 들어, 도 48a 내지 도 48e와 관련하여 이하에서 기술되는 것과 같은 다른 네트워크 프로토콜에 따라 구성될 수 있다.
이제 도 1c를 참조하면, 각각의 N-SC(30a 내지 30c)는 응용 프로그램 활성화(application enablement) 능력("AE"); 일반 통신(generic communication) 능력("GC"); 도달성, 어드레싱 및 저장소(reachability, addressing and repository) 능력("RAR"); 통신 선택(communication selection) 능력("CS"); 원격 엔터티 관리(remote entity management) 능력("REM"); 보안(security) 능력("SEC"); 이력 및 데이터 유지(history and data retention) 능력("HDR"); 트랜잭션 관리(transaction management) 능력(“TM"); 연동 프록시(interworking proxy) 능력("IP"), 및 통신 사업자 노출(telecom operator exposure) 능력("TOE")을 포함하거나 포함하도록 구성되어 있을 수 있고; 이들 각각은 한 능력으로부터 다른 능력으로 (예컨대, 처리된 메시지로부터의) 정보를 전달하는 라우팅 기능에 연결되어 있을 수 있다. 각각의 N-SC(30a 내지 30c)는 또한 내부 소프트웨어를 스케줄링하고, 운영 체제 인터페이스를 관리하며, 기타 등등을 하는 관리자를 포함하고 있을 수 있다.
각각의 G-SC(56a, 56b) 및 각각의 D-SC(46a 내지 46d)는 또한, 관리자와 함께, 라우팅 기능에 연결되어 있는 AE, GC, RAR, CS, REM, SEC, HDR, TM 및 IP를 포함하고 있을 수 있다. N-SC, G-SC 및 D-SC를 구별하기 위해, 편의상, 이후부터 "N", "G" 또는 "D"의 프리픽스가 AE, GC, RAR, CS, REM, SEC, HDR, TM, 라우팅 기능 및 관리자에 부가될 수 있다. N-SC, G-SC 및 D-SC를 모두 합하여 지칭하기 위해, "x"의 프리픽스가 AE, GC, RAR, CS, REM, SEC, HDR, TM, 라우팅 기능 및 관리자에 부가될 수 있다.
디바이스간(device-to-device)(D2D), 게이트웨이간(gateway-to-gateway)(G2G) 및 서비스간(service-to-server)(S2S) 직접 통신을 가능하게 해주기 위해, 각각의 N-SC(30a 내지 30c), G-SC(56a, 56b) 및 D-SC(46a 내지 46d)는 또한 SC간(SC-to-SC) 상호작용 능력을 포함할 수 있다. N-SC(30a 내지 30c), G-SC(56a, 56b) 및 D-SC(46a 내지 46d)(모두 합하여 "xSC") 중 일부 또는 전부의 일부분이, 예를 들어, ETSI TS 102 690 등의 M2M 통신 및/또는 운용에 관련된 표준에 따라 정의될 수 있다.
일반적으로, SC는 다양한 M2M 응용 프로그램에 의해 이용될 수 있는 기능을 정의 및/또는 구현할 수 있다. 이것을 용이하게 해주기 위해, SC(24)는 한 세트의 개방 인터페이스를 통해 이러한 기능을 다양한 M2M 응용 프로그램에 노출시킬 수 있다. 그에 부가하여, SC는 액세스/코어 및/또는 전송 네트워크(20, 22)의 기능("네트워크 기능")을 사용할 수 있다. 그렇지만, SC는 네트워크 상세를 다양한 M2M 응용 프로그램으로부터 숨길 수 있고, 그 대신에, SC를 통해 이러한 응용 프로그램에 대한 네트워크 관리를 처리할 수 있다. SC는 M2M에 고유할 수 있다. 다른 대안으로서, SC는 일반적일 수 있다(즉, M2M 응용 프로그램 및 M2M 응용 프로그램 이외의 응용 프로그램에 대한 지원을 제공함). 이하에서 더 상세히 기술되는 바와 같이, 각각의 N-SCL 리소스 구조체(32a 내지 32c), G-SCL 리소스 구조체(58a 내지 58e) 및/또는 D-SCL(44a 내지 44d)은, 하나 이상의 xSC의 아키텍처에 기초하여, 계층구조로 배열되어 있을 수 있는 하나 이상의 리소스 및/또는 속성을 포함할 수 있다.
예시적인 xREM 관리 계층 및 기능
도 2는 xREM을 수행하는 기능적 아키텍처를 정의하는 논리 관리 계층들(200)의 예시적인 세트를 나타낸 블록도이다. 일반적으로, 관리 계층(200)은 통신 모듈, SCL 및 응용 프로그램을 관리하는 기능을 정의할 수 있다. 관리 계층(200)은 또한 관리 기능을 구별하고, 대응하는 관리 객체 및 리소스 구조체를 정의하며, xREM에서 M2M 디바이스("DREM"), M2M 게이트웨이("GREM"), 및 M2M 영역 네트워크("NREM")에 대한 관리 기능을 각각 식별할 수 있다. 관리 계층(200)의 관리 기능을 구별하는 것은 M2M 원격 엔터티의 유형에 기초할 수 있다. 관리 계층(200)은, 예를 들어, (i) M2M 응용 프로그램(들), (ii) M2M SC(들); (iii) M2M 영역 네트워크(들) 및 M2M 게이트웨이(들); 및 (iv) M2M 디바이스(들)를 관리하는 기능을 정의하는 개별적인 층을 포함할 수 있다. 각각의 관리 계층(200)은 이러한 관리 계층에 존재하는 M2M 원격 엔터티의 구성 관리(210), 장애 관리(212), 성능 관리(213) 등을 수행하는 기능을 포함할 수 있다. 일 실시예에서, 관리 계층(200)은 응용 프로그램 관리 계층(202), 서비스 관리 계층(204), 네트워크 관리 계층(206) 및 디바이스 관리 계층(208)을 포함할 수 있다. 관리 계층(200)은 다른 계층도 포함할 수 있다.
예시적인 M2M 응용 프로그램 관리 계층
M2M 응용 프로그램 관리 계층(202)은 관리 기능을 정의하는 것, 관리 객체 및 리소스 구조체를 정의하는 것, 및 M2M 응용 프로그램을 관리하는 것과 연관되어 있는 xREM에서의 관리 기능을 식별하는 것을 비롯하여 M2M 응용 프로그램을 관리하는 것을 처리할 수 있다. M2M 응용 프로그램 관리 계층(202)은 M2M 디바이스 및/또는 M2M 게이트웨이(모두 합하여, "D/G"라고 함)에서의 M2M 디바이스 응용 프로그램의 라이프 사이클 관리(D/G에서의 응용 프로그램 소프트웨어를 설치, 업데이트, 삭제, 활성화, 비활성화하는 것 중 임의의 것을 포함할 수 있음)를 처리할 수 있다. M2M 응용 프로그램 관리 계층(202)은 또한 D/G에서의 응용 프로그램의 구성 관리를 처리할 수 있다. 이것은, 예를 들어, 이러한 응용 프로그램의 초기 설정 및/또는 그에 대한 업데이트를 구성하고 및/또는 프로비저닝하는 것을 포함할 수 있다. M2M 응용 프로그램 관리 계층(202)은, 예를 들어, 장애 관련 정보를 수집하고 및/또는 검색하는 것을 비롯하여 D/G에서의 응용 프로그램의 장애 관리를 처리할 수 있다. M2M 응용 프로그램 관리 계층(202)은, 예를 들어, 성능 관련 정보를 수집하고 및/또는 검색하는 것을 비롯하여 D/G에서의 응용 프로그램의 성능 관리를 처리할 수 있다. M2M 응용 프로그램 관리 계층(202)의 소유자는, 예를 들어, M2M 응용 프로그램 제공자일 수 있다.
예시적인 M2M 서비스 관리 계층
M2M 서비스 관리 계층(204)은 관리 기능을 정의하는 것, 관리 객체 및 리소스 구조체를 정의하는 것, 및 M2M SC를관리하는 것과 연관되어 있는 xREM에서의 관리 기능을 식별하는 것을 비롯하여 M2M SC를 관리하는 것을 처리할 수 있다. M2M 서비스 관리 계층(204)은 D/G에서의 SCL의 소프트웨어/펌웨어 업데이트; SCL의 초기 설정 및/또는 그에 대한 업데이트를 구성하거나 프로비저닝하는 것을 비롯한 D/G에서의 SCL의 구성 관리; 예를 들어, 장애 관련 정보를 수집하고 검색하는 것을 비롯한 D/G에서의 SCL의 장애 관리; 및 성능 관련 정보를 수집하고 검색하는 것을 포함할 수 있는 D/G에서의 SCL의 성능 관리를 처리할 수 있다. M2M 서비스 관리 계층(204)의 소유자는, 예를 들어, M2M 서비스 제공자일 수 있다.
예시적인 M2M 네트워크 관리 계층
M2M 네트워크 관리 계층(206)은 관리 기능을 정의하는 것, 관리 객체 및 리소스 구조체를 정의하는 것, 및 M2M 영역 네트워크를 관리하는 것과 연관되어 있는 xREM에서의 관리 기능을 식별하는 것을 비롯한 M2M 영역 네트워크를 관리하는 것을 처리할 수 있다. 예를 들어, 이 계층은 라우팅 관리, 토폴로지 관리, 및 네트워크 수명 관리를 제어할 수 있다. M2M 영역 네트워크가, 많은 경우에, M2M GW에 의해 연결되기 때문에, M2M GW는 네트워크 관리 계층(206)에서 역할을 할 수 있다.
M2M 네트워크 관리 계층(206)은, 예를 들어, M2M 영역 네트워크의 초기 동작 구성을 구성하고 및/또는 프로비저닝하는 것 - IPv6 주소 프리픽스, 동작 주파수, WPAN ID 등을 구성하는 것을 포함할 수 있음 - 을 비롯한 M2M 영역 네트워크의 구성 관리를 처리할 수 있다. M2M 네트워크 관리 계층(206)은 또한 (i) 6LoWPAN/ROLL/CoAP에서 파라미터 및/또는 상수를 업데이트하는 것을 포함할 수 있는 D/G의 구성을 업데이트하는 것; (ii) 이상 검출(예를 들어, 오래된 또는 잘못된 경로, 루프백 경로) 및/또는 경보 발생 및/또는 처리를 비롯한 M2M 영역 네트워크의 장애 관리; (iii) (예컨대, 전체) M2M 영역 네트워크의 듀티비 관리, 토폴로지/경로 관리 및 QoS 관리 중 임의의 것을 포함할 수 있는 M2M 영역 네트워크의 성능 관리를 처리할 수 있다. 네트워크 관리 계층(206)의 소유자는 M2M 응용 프로그램 제공자, M2M 서비스 제공자 또는 M2M 사용자일 수 있는 M2M 영역 네트워크 제공자일 수 있다.
예시적인 M2M 디바이스 관리 계층
디바이스 관리 계층(208)은 관리 기능을 정의하는 것, 관리 객체 및 리소스 구조체를 정의하는 것, 및 M2M 종단 디바이스와 연관되어 있는 xREM에서의 관리 기능을 식별하는 것을 비롯한 D/G 등의 M2M 종단 디바이스를 관리하는 것을 처리할 수 있다. 디바이스 관리 계층(208)은 리소스 제약된 M2M 디바이스에 대한 관리 기능 - 예를 들어, 듀티비 관리 및 전력 관리를 포함할 수 있음 - 을 처리할 수 있고, 디바이스 관리 계층(208)은 (i) D/G의 초기 동작을 구성하는 것 및/또는 D/G의 구성을 업데이트하는 것을 포함할 수 있는 D/G의 구성 관리; (ii) 이상 검출 및 경보 발생 및 처리 중 임의의 것을 포함할 수 있는 D/G의 장애 관리; (iii) 예를 들어, 제약된 리소스(센서, 작동기, 전원/배터리, 메모리, CPU, 통신 인터페이스 등)의 관리, 전력 절감 관리[예컨대, 전체 노드의 듀티비, 송수신기(들)의 듀티비], 및 센서/작동기 관리(예컨대, 상이한 응용 프로그램 간의 공유) 중 임의의 것을 포함할 수 있는 D/G의 성능 관리를 처리할 수 있다. 디바이스 관리 계층(208)의 소유자는 M2M 응용 프로그램 제공자, M2M 서비스 제공자, M2M 영역 네트워크 제공자 또는 M2M 사용자일 수 있다.
도 3a를 참조하면, 한 세트의 관리 계층 및 그의 기능에 따라 리소스 구조체로 SCL을 프로비저닝하는 예시적인 리소스 구조체 프레임워크(300)를 나타낸 블록도가 도시되어 있다. 이러한 리소스 구조체가 프로비저닝될 수 있는 SCL은, 예를 들어, N-SCL들(26a 내지 26c) 중 임의의 것 등의 호스팅 SCL일 수 있다. 호스팅 SCL에서 프로비저닝되는 리소스 구조체는, 호스팅 SCL, 다른 호스팅 SCL 및/또는 원격 SCL 간의 동기화에 의해, 하나 이상의 다른 호스팅 SCL에서 및/또는 G-SCL(56a, 56b) 및/또는 D-SCL(44a 내지 44d) 등의 하나 이상의 원격 SCL에서 차후에 프로비저닝(예컨대, 전체적으로 또는 부분적으로 복제)될 수 있다. 다른 대안으로서, 이러한 리소스 구조체가 프로비저닝될 수 있는 SCL은 G-SCL(56a, 56b) 및/또는 D-SCL(44a 내지 44d) 중 임의의 것 등의 원격 SCL일 수 있다. 원격 SCL에서 프로비저닝되는 리소스 구조체는, 원격 SCL, 다른 원격 SCL 및/또는 호스팅 SCL 간의 동기화에 의해, 하나 이상의 다른 원격 SCL에서 및/또는 N-SCL(26a 내지 26c) 등의 하나 이상의 호스팅 SCL에서 차후에 프로비저닝(예컨대, 전체적으로 또는 부분적으로 복제)될 수 있다. 그에 부가하여 및/또는 다른 대안으로서, 다수의 호스팅 SCL 및/또는 다수의 원격 SCL에서 리소스 구조체를 프로비저닝하기 위해서도 리소스 구조체 프레임워크(300)가 사용될 수 있다.
리소스 구조체 프레임워크(300)는 적절한 SCL의 루트 리소스(root resource)("<sclBase>")(302), <sclBase>(302)에 종속되어 있는 복수의 리소스("서브리소스") 및 하나 이상의 속성(attribute)(304)을 포함할 수 있다. 속성(304)은 <sclBase>(302)로부터 직접 종속되어 있는 서브리소스들 중 일부 또는 전부와 연관되어 있을 수 있다(예컨대, 그에 공통임). 다른 대안으로서, 속성(304)은 <sclBase>(302)로부터 직접 및/또는 간접적으로 종속되어 있는 서브리소스와 연관되어 있을 수 있다. <sclBase>(302)로부터 직접 종속되어 있는 서브리소스는 SCL("scls") 서브리소스(306), 응용 프로그램("applications") 서브리소스(308), 컨테이너("containers") 서브리소스(310), 그룹("groups") 서브리소스(312), 액세스 권한("accessRights") 서브리소스(314), 가입("subscriptions") 서브리소스(316), 발견("discovery") 서브리소스(318), 액세스 상태("accessStatus") 서브리소스(320), 및 관리 객체("mgmtObjs") 서브리소스(322)를 포함할 수 있다.
scls 서브리소스(306)는 개별 SCL 리소스들의 모음일 수 있고; 이들 각각은, 예컨대, M2M 서비스 등록 절차를 통해 호스팅 SCL과 상호작용하도록 허가되어 있는 연관된(예컨대, 원격) SCL을 나타낼 수 있다. scls 서브리소스(306)의 각각의 SCL 리소스는 연관된 SCL의 그의 로컬 SCL에의 성공적인 등록 또는 그 반대에 응답하여 생성될 수 있다. scls 서브리소스(306)는 각자의 등록된 SCL에 관한 컨텍스트 정보를 포함, 유지 및/또는 저장할 수 있다. 각각의 scls 서브리소스(306)는 하나 이상의 서브리소스 및/또는 하나 이상의 속성(도시 생략)을 포함할 수 있다.
applications 서브리소스(308)는 개별 응용 프로그램 리소스들의 모음일 수 있고; 이들 각각은 응용 프로그램에 관한 정보를 포함, 유지 및/또는 저장할 수 있다. applications 서브리소스(308)의 각각의 응용 프로그램 리소스는 연관된 응용 프로그램의 로컬 SCL에의 성공적인 등록에 응답하여 생성될 수 있다.
containers 서브리소스(310)는 개별 컨테이너 리소스들의 모음일 수 있고; 이들 각각은 응용 프로그램 및/또는 SCL 간의 정보 교환에서 사용하는 일반 리소스(generic resource)일 수 있다. containers 서브리소스(310)의 각각의 컨테이너 리소스는, 대응하는 컨테이너를 정보를 버퍼링하는 매개자(mediator)로서 사용하여, 응용 프로그램 및/또는 SCL 간의 정보의 교환을 용이하게 해줄 수 있다.
groups 서브리소스(312)는 개별 그룹 리소스들의 모음일 수 있다. groups 서브리소스(312)의 각각의 그룹 리소스는 <sclBase>(302)로부터 직접 및/또는 간접적으로 종속되어 있는 서브리소스를 비롯한 다른 서브리소스의 그룹을 정의하고 및/또는 그에 액세스하는 데 사용될 수 있다.
accessRights 서브리소스(314)는 개별 액세스 권한("accessRight") 리소스들의 모음일 수 있고; 이들 각각은 허가(permission)의 표시를 포함, 유지 및/또는 저장할 수 있다. accessRights 서브리소스(314)의 각각의 accessRight 리소스는 호스팅 SCL 외부에 있는 엔터티에 의해 액세스가능할 수 있는 하나 이상의 다른 서브리소스와 연관되어 있을 수 있다. 각각의 accessRights(314)의 허가의 표현은 허가 보유자(permission holder)의 식별자 및 허가 보유자에 부여된 권한의 식별자를 포함할 수 있다. 허가 보유자에 부여된 권한의 식별자는, 예를 들어, 대응하는 서브리소스에 대해 부여된 하나 이상의 권한과 연관되어 있는 허가 플래그(permission flag)일 수 있다.
subscriptions 서브리소스(316)는 개별 가입 리소스들의 모음일 수 있다. subscriptions(316)의 각각의 가입 리소스는 (예컨대, 활성) 가입의 상태를 그의 부모 리소스[즉, <sclBase>(302)]까지 추적하기 위한 정보를 포함할 수 있다. 각각의 subscriptions(316)은 <sclBase>(302)에 대한 수정을 통지하라는 발행자로부터의 요청을 나타낼 수 있다.
discovery(318)는 서브리소스의 발견을 가능하게 해주기 위해 사용될 수 있다. discovery(318)는 발견 필터 기준과 일치하는 서브리소스의 "URI"(uniform resource identifier)의 목록을 검색하는 데 사용될 수 있다. accessStatus(320)는 개별 액세스 상태 리소스들의 모음일 수 있다.
mgmtObjs 서브리소스(322)는 개별 관리 객체("mgmtObj") 리소스들의 모음일 수 있다. mgmtObjs(322)의 각각의 mgmtObj 리소스는 REM을 수행하기 위한 관리 정보 및/또는 파라미터를 포함, 유지 및/또는 저장할 수 있다. mgmtObjs 서브리소스(322)는 응용 프로그램 관리 객체 서브리소스("appMgmtObjects") 서브리소스(324), SCL 관리 객체 서브리소스("sclMgmtObjects") 서브리소스(326), 네트워크 관리 객체 서브리소스("nwkMgmtObjects") 서브리소스(328), 디바이스 관리 객체 서브리소스("devMgmtObjects") 서브리소스(330), OMA-DM 관리 객체 서브리소스("omaMgmtObjects") 서브리소스(332) 및 BBF-TR069 관리 객체 서브리소스("bbfMgmtObjects") 서브리소스(334)를 포함할 수 있다. mgmtObjs 서브리소스(322)는 다른 및/또는 상이한 mgmtObj 리소스도 포함할 수 있다.
appMgmtObjects 서브리소스(324)는 개별 응용 프로그램 관리 객체("appMgmtObject") 리소스들의 모음일 수 있다. 각각의 appMgmtObject 리소스는 응용 프로그램 관리 계층(202)(도 2) 등의 응용 프로그램 관리 계층 및 그의 기능에 따라 REM을 수행하기 위한 정보 및/또는 파라미터를 포함할 수 있다. 각각의 appMgmtObject 리소스는 <mgmtObject> 인스턴스(324-1)로서 appMgmtObjects 서브리소스(324)에 종속되어 배치될 수 있다.
sclMgmtObjects 서브리소스(326)는 개별 SCL 관리 객체("sclMgmtObject") 리소스들의 모음일 수 있다. 각각의 sclMgmtObject 리소스는 서비스 관리 계층(204)(도 2) 등의 서비스 관리 계층 및 그의 기능에 따라 REM을 수행하기 위한 정보 및/또는 파라미터를 포함할 수 있다. 각각의 sclMgmtObject 리소스는 <mgmtObject> 인스턴스(326-1)로서 sclMgmtObjects 서브리소스(326)에 종속되어 배치될 수 있다.
nwkMgmtObjects 서브리소스(328)는 개별 네트워크 관리 객체("nwkMgmtObject") 리소스들의 모음일 수 있다. 각각의 nwkMgmtObject 리소스는 네트워크 관리 계층(206)(도 2) 등의 네트워크 관리 계층 및 그의 기능에 따라 REM을 수행하기 위한 정보 및/또는 파라미터를 포함할 수 있다. 각각의 nwkMgmtObject 리소스는 <mgmtObject> 인스턴스(328-1)로서 nwkMgmtObjects 서브리소스(328)에 종속되어 배치될 수 있다.
devMgmtObjects 서브리소스(330)는 개별 디바이스 관리 객체("devMgmtObject") 리소스들의 모음일 수 있다. 각각의 devMgmtObject 리소스는 디바이스 관리 계층(208)(도 2) 등의 디바이스 관리 계층 및 그의 기능에 따라 REM을 수행하기 위한 정보 및/또는 파라미터를 포함할 수 있다. 각각의 devMgmtObject 리소스는 <mgmtObject> 인스턴스(330-1)로서 devMgmtObjects 서브리소스(330)에 종속되어 배치될 수 있다.
omaMgmtObjects(332)는 개별 OMA-DM 관리 객체("omaMgmtObject") 리소스들의 모음일 수 있다. 각각의 omaMgmtObject 리소스는 OMA-DM 및/또는 OMA-DM 호환 관리 기능에 따라 REM을 수행하기 위한 정보 및/또는 파라미터를 포함할 수 있다. 각각의 omaMgmtObject 리소스는 <mgmtObject> 인스턴스(332-1)로서 omaMgmtObjects 서브리소스(332)에 종속되어 배치될 수 있다.
bbfMgmtObjects 서브리소스(334)는 개별 BBF-TR069 관리 객체("bbfMgmtObject") 리소스들의 모음일 수 있다. 각각의 bbfMgmtObject 리소스는, 예를 들어, BBF-TR069 RPC(Remote Procedure Call, 원격 프로시저 호출) 메소드 등의 BBF-TR069 및/또는 BBF-TR069 호환 관리 기능에 따라 REM을 수행하기 위한 정보 및/또는 파라미터를 포함할 수 있다. 각각의 bbfMgmtObject 리소스는 <mgmtObject> 인스턴스(334-1)로서 bbfMgmtObjects 서브리소스(334)에 종속되어 배치될 수 있다.
비록 mgmtObjs 서브리소스(322)가, 도 3a에 도시된 바와 같이, <sclBase-of-Server>/scls/<scl>/mgmtObjs에만 존재하지만, 다른(예컨대, 다수의) mgmtObjs 서브리소스가 <sclBase>(302)의 다양한 추가의 종속된 분기/위치에 위치될 수 있다. 이 방식으로, 이러한 다른 mgmtObjs 서브리소스는 특정의 관리 기능에(응용 프로그램 또는 SCL 등에) 명시적으로 대응할 수 있다.
도 3b는 한 세트의 관리 계층 및 그의 기능에 따라 리소스 구조체로 SCL을 프로비저닝하는 예시적인 리소스 구조체 프레임워크(340)를 나타낸 블록도이다. 이러한 리소스 구조체가 프로비저닝될 수 있는 SCL은, 예를 들어, G-SCL(56a, 56b) 및/또는 D-SCL(44a 내지 44d) 중 임의의 것 등의 로컬 SCL일 수 있다. 로컬 SCL에서 프로비저닝되는 리소스 구조체는, 로컬 SCL 및/또는 호스팅 SCL 간의 동기화에 의해, 하나 이상의 다른 호스팅 SCL에서 및/또는 N-SCL(26a 내지 26c) 등의 하나 이상의 원격 SCL에서 차후에 프로비저닝(예컨대, 전체적으로 또는 부분적으로 복제)될 수 있다. 다른 대안으로서, 이러한 리소스 구조체가 프로비저닝될 수 있는 SCL은 N-SCL들(26a 내지 26c) 중 임의의 것 등의 호스팅 SCL일 수 있다. 호스팅 SCL에서 프로비저닝되는 리소스 구조체는, 호스팅 SCL 및 원격 SCL 간의 동기화에 의해, G-SCL(56a, 56b) 및/또는 D-SCL(44a 내지 44d) 등의 하나 이상의 다른 원격 SCL에서 차후에 프로비저닝(예컨대, 전체적으로 또는 부분적으로 복제)될 수 있다. 그에 부가하여 및/또는 다른 대안으로서, 다수의 로컬 SCL 및/또는 다수의 호스팅 SCL에서 리소스 구조체를 프로비저닝하기 위해서도 리소스 구조체 프레임워크(340)가 사용될 수 있다.
리소스 구조체 프레임워크(340)는 <sclBase>(342), <sclBase>(342)에 대한 복수의 서브리소스, <sclBase>(342)에 직접 종속되어 있는 서브리소스들 중 일부 또는 전부와 연관되어 있는 하나 이상의 속성(344), 및 <sclBase>(342)로부터 간접적으로 종속되어 있는 서브리소스와 연관되어 있는 속성(350 및 360)을 포함할 수 있다.
<sclBase>(342)로부터 직접 종속되어 있는 서브리소스는, 다음과 같은 경우를 제외하고는, 도 3a의 <sclBase>(302)로부터 직접 종속되어 있는 서브리소스와 유사할 수 있다. <sclBase>(342)로부터 직접 종속되어 있는 서브리소스는 applications 서브리소스(346) 및 mgmtObjs 서브리소스(348)를 포함할 수 있다.
(<sclBase>/mgmtObjs에 있는) mgmtObjs 서브리소스(348)는 개별 관리 객체("mgmtObj") 리소스들의 모음일 수 있다. mgmtObjs 서브리소스(348)는 (i) 서비스 관리 계층 및 그의 기능, (ii) 네트워크 관리 계층 및 그의 기능, (iii) 디바이스 관리 계층 및 그의 기능, (iv) OMA-DM 및/또는 OMA-DM 호환 관리 기능, 및 (v) BBF-TR069 및/또는 BBF-TR069 호환 관리 기능 중 임의의 것에 따라 REM을 수행하기 위한 관리 정보 및/또는 파라미터를 포함, 유지 및/또는 저장할 수 있다. mgmtObjs 서브리소스(348)는, 예를 들어, sclMgmtObjects 서브리소스(326), nwkMgmtObjects 서브리소스(328), devMgmtObjects 서브리소스(330), omaMgmtObjects 서브리소스(332) 및 bbfMgmtObjects 서브리소스(334)를 포함할 수 있다. mgmtObjs 서브리소스(348)는 다른 및/또는 상이한 mgmtObj 리소스도 포함할 수 있다.
applications 서브리소스(346)는 개별 응용 프로그램("<application>) 리소스(352), accessStatus 서브리소스(354), subscriptions 서브리소스(356), mgmtObjs 서브리소스(358) 및 applications 서브리소스(346)의 서브리소스와 연관되어 있는 속성(attribute)(350)을 포함할 수 있다. (<sclBase>/applications/mgmtObjs에 있는) mgmtObjs 서브리소스(358)는 전체로서 <sclBase>(342) 아래에 등록되어 있는 모든 응용 프로그램의 REM을 수행하는 서브리소스들의 모음을 포함할 수 있다.
각각의 개별 응용 프로그램 리소스(352)는 containers 서브리소스(362), groups 서브리소스(364), accessRights 서브리소스(366), accessStatus 서브리소스(368), subscriptions 서브리소스(370), mgmtObjs 서브리소스(372) 및 대응하는 개별 응용 프로그램 리소스(352)의 서브리소스와 연관되어 있는 속성(360)을 포함할 수 있다. (<sclBase>/applications/<application>/mgmtObjs에 있는) mgmtObjs 서브리소스(372)는 대응하는 <application> 서브리소스(352)와 연관되어 있는 특정의 <application>의 REM을 수행하는 서브리소스들의 모음을 포함할 수 있다.
도 3c는 한 세트의 관리 계층 및 그의 기능에 따라 리소스 구조체로 SCL을 프로비저닝하는 예시적인 리소스 구조체 프레임워크(376)를 나타낸 블록도이다. 이러한 리소스 구조체가 프로비저닝될 수 있는 SCL은, 예를 들어, N-SCL들(26a 내지 26c) 중 임의의 것 등의 호스팅 SCL일 수 있다. 호스팅 SCL에서 프로비저닝되는 리소스 구조체는, 호스팅 SCL, 다른 호스팅 SCL 및/또는 원격 SCL 간의 동기화에 의해, 하나 이상의 다른 호스팅 SCL에서 및/또는 G-SCL(56a, 56b) 및/또는 D-SCL(44a 내지 44d) 등의 하나 이상의 원격 SCL에서 차후에 프로비저닝(예컨대, 전체적으로 또는 부분적으로 복제)될 수 있다. 다른 대안으로서, 이러한 리소스 구조체가 프로비저닝될 수 있는 SCL은 G-SCL(56a, 56b) 및/또는 D-SCL(44a 내지 44d) 중 임의의 것 등의 원격 SCL일 수 있다. 원격 SCL에서 프로비저닝되는 리소스 구조체는, 원격 SCL, 다른 원격 SCL 및/또는 호스팅 SCL 간의 동기화에 의해, 하나 이상의 다른 원격 SCL에서 및/또는 N-SCL(26a 내지 26c) 등의 하나 이상의 호스팅 SCL에서 차후에 프로비저닝(예컨대, 전체적으로 또는 부분적으로 복제)될 수 있다. 그에 부가하여 및/또는 다른 대안으로서, 다수의 호스팅 SCL 및/또는 다수의 원격 SCL에서 리소스 구조체를 프로비저닝하기 위해서도 리소스 구조체 프레임워크(340)가 사용될 수 있다.
리소스 구조체 프레임워크(376)는 <sclBase>(378), <sclBase>(378)에 대한 복수의 서브리소스, 및 <sclBase>(378)로부터 직접 및/또는 간접적으로 종속되어 있는 서브리소스들 중 일부 또는 전부와 연관되어 있는 하나 이상의 속성을 포함할 수 있다. <sclBase>(378)로부터 직접 종속되어 있는 서브리소스는, 어떤 mgmtObjs 리소스도 <sclBase>(378)로부터 직접 종속되어 있지 않은 것을 제외하고는, 도 3a의 <sclBase>(302)로부터 직접 종속되어 있는 서브리소스와 유사하다. 그 대신에, 리소스 구조체 프레임워크(376)는 <sclBase>(376)의 다양한 추가의 종속된 분기/위치에 위치될 수 있는 다수의 mgmtObjs 서브리소스를 포함하고 있다. 예를 들어, <sclBase>(376)는 (<sclBase>scls/mgmtObjs에 있는) mgmtObjs 서브리소스(380)를 포함할 수 있다. mgmtObjs 서브리소스(380)는 전체로서 M2M 서버에 등록되어 있는 모든 SCL의 REM을 수행하는 서브리소스들의 모음을 포함할 수 있다. 이들 서브리소스는 서비스 관리 계층(204)(도 2) 등의 서비스 관리 계층 및 그의 기능에 따라 전체로서 M2M 서버에 등록되어 있는 모든 SCL의 REM을 수행하기 위한 정보 및/또는 파라미터를 포함할 수 있다.
<sclBase>(376)는 또한 (<sclBase>/scls/<scl>/mgmtObjs에 있는) mgmtObjs 서브리소스(382)를 포함할 수 있다. 이 mgmtObjs 서브리소스(382)는 M2M 서버에 등록되어 있는 <scl>의 서비스 능력 및 다른 관리 기능(네트워크 관리 계층 및 디바이스 관리 계층)의 REM을 수행하는 서브리소스들의 모음을 포함할 수 있다. 일 실시예에서, 서브리소스는 (i) 네트워크 관리 계층(206)(도 2) 등의 네트워크 관리 계층 및 그의 기능; 및 (ii) 디바이스 관리 계층(208)(도 2) 등의 디바이스 관리 계층에 따라 M2M 서버에 등록되어 있는 <scl>의 서비스 능력 및 기타 관리 기능의 REM을 수행하기 위한 정보 및/또는 파라미터를 포함할 수 있다.
<sclBase>(376)는 또한 (<sclBase>/scls/<scl>/applications//mgmtObjs에 있는) mgmtObjs 서브리소스(384)를 포함할 수 있다. mgmtObjs 서브리소스(384)는 전체로서 서버에 공지되는 모든 응용 프로그램의 REM을 수행하는 서브리소스들의 모음을 포함할 수 있다. <sclBase>(376)는 (<sclBase>/scls/<scl>/applications/<applicationAnnc>/mgmtObjs에 있는) mgmtObjs 서브리소스(386)를 추가로 포함할 수 있다. 이 mgmtObjs 서브리소스(386)는 M2M 서버에 공지되는 특정의 <applicationAnnc>의 REM을 수행하는 서브리소스들의 모음을 포함할 수 있다.
일 실시예에서, (<sclBase>/scls/<scl>/mgmtObjs에 있는) mgmtObjs 서브리소스(382)는 M2M 서버에 등록되는 다른 D/G를 관리하기 위해 DA 및/또는 GA에 의해 사용될 수 있다. M2M 서버(즉, <scl>)는 그의 <mgmtObj>를 D/G에 공지할 수 있다. 이어서, DA/GA가 D/G에서의 이러한 공지된 <mgmtObj>에 액세스할 수 있고, 차례로 M2M 서버에서의 메시지 중계를 통해 다른 D/G를 관리할 수 있다.
도 4a는 mgmtObjs로 SCL을 프로비저닝하는 예시적인 리소스 구조체 프레임워크(400)를 나타낸 블록도이다. 리소스 구조체 프레임워크("mgmtObjs 구조체 프레임워크")(400)는, 루트로서, mgmtObjs(402), mgmtObjs(402)에 대한 복수의 서브리소스, mgmtObjs(402)에 직접 종속되어 있는 서브리소스들 중 일부 또는 전부와 연관되어 있는 하나 이상의 속성(404), 및 mgmtObjs(402)로부터 간접적으로 종속되어 있는 서브리소스와 연관되어 있는 속성(416, 418, 430, 및 442)을 포함할 수 있다. 속성(404)은 accessRightID; creationTime; lastModifiedTime; mgmtObjs(402)의 텍스트 형식 설명 등의 설명(description); 및 allowedMethod를 포함할 수 있다. allowedMethod는 mgmtObjs 서브리소스(402)를 처리하는 허용된 RESTful 메소드(들)를 지정할 수 있다.
mgmtObjs(402)에 대한 복수의 서브리소스는 mgmtObj("<mgmtObj>") 서브리소스(406), 관리 객체 공지(management object announce)("<mgmtObjAnnc>") 서브리소스(408), accessRights 서브리소스(410), accessStatus 서브리소스(412) 및 subscriptions 서브리소스(414)를 포함할 수 있다.
<mgmtObj> 서브리소스(406)는 이 <mgmtObj> 서브리소스(406)에 대한 관련 관리 데이터/파라미터를 저장하는 특정의 관리 객체 및 자리 표시자(placeholder)일 수 있다. <mgmtObjAnnc> 서브리소스(408)는 공지된(announced) 관리 객체에 대한 자리 표시자일 수 있다. <mgmtObjAnnc> 서브리소스(408)는 다음과 같은 속성 (i) 링크, (ii) accessRightID, 및 (iii) searchStrings를 포함할 수 있다.
<accessRights> 서브리소스(410)는 REM을 수행하는 데 사용되는 서브리소스에 대한 허가의 표현을 포함, 유지 및/또는 저장할 수 있다. <accessRights> 서브리소스(408)는 그의 부모(있는 경우)로부터 상속될 수 있다.
accessStatus 서브리소스(414)는 개별 액세스 상태 리소스들의 모음일 수 있다. subscriptions 서브리소스(414)는 가입 리소스들의 모음일 수 있고; 이들 각각은 (예컨대, 활성) 가입의 상태를 그의 부모 리소스까지 추적하기 위한 정보를 포함할 수 있다. 각각의 subscriptions(414)은 부모 리소스에 대한 수정을 통지하라는 발행자로부터의 요청을 나타낼 수 있다.
<mgmtObj> 서브리소스(406)는 (i) 관리를 위한 다수의 파라미터들의 모음에 대한 자리 표시자일 수 있는 <parameters> 서브리소스(420); (ii) 단일의 관리 파라미터일 수 있는 <parameter> 서브리소스(422); (iii) xREM을 위한 <accessRights> 서브리소스(424); (iv) <accessStatus> 서브리소스(426); 및 (v) <subscriptions> 서브리소스(428)를 포함할 수 있다. <accessRights> 서브리소스(424)는 REM을 수행하는 데 사용되는 서브리소스에 대한 허가의 표현을 포함, 유지 및/또는 저장할 수 있다. <accessRights> 서브리소스(424)는 그의 부모(있는 경우)로부터 상속될 수 있다.
<mgmtObj> 서브리소스(406)는 다음과 같은 속성 (i) accessRightID, creationTime, lastModifiedTime, 설명[예컨대, <mgmtObj> 서브리소스(406)의 텍스트 형식 설명], allowedMethod, 및 contentType을 포함할 수 있다. allowedMethod는 <mgmtObj> 서브리소스(406)를 처리하는 허용된 RESTful 메소드(들)를 지정할 수 있다. contentType은 <mgmtObj> 서브리소스(406)의 유형을 지정할 수 있다. contentType 속성은 dataType 속성이라고도 할 수 있다.
<parameters> 서브리소스(420)는 <parameters> 서브리소스(432)를 포함할 수 있다. <parameters> 서브리소스(432)는 관리를 위한 다수의 파라미터들의 모음에 대한 자리 표시자일 수 있다. <parameters> 서브리소스(432)를 <parameters> 서브리소스(420)에 종속되게 함으로써, 계층적 트리 구조가 지원될 수 있고, 기존의 관리 객체의 임포트가 플랫 구조체(flat structure)보다 더 간단할 수 있다.
<parameters> 서브리소스(420)는 또한 (i) 단일의 관리 파라미터를 유지 및/또는 저장하는 <parameter> 서브리소스(434); (ii) xREM을 위한 <accessRights> 서브리소스(436); (iii) <accessStatus> 서브리소스(438); 및 <subscriptions> 서브리소스(440)를 포함할 수 있다. <accessRights> 서브리소스(436)는 REM을 수행하는 데 사용되는 서브리소스에 대한 허가의 표현을 포함, 유지 및/또는 저장할 수 있다. <accessRights> 서브리소스(436)는 그의 부모(있는 경우)로부터 상속될 수 있다.
<parameters> 서브리소스(420)는 다음과 같은 속성 (i) accessRightID, (ii) creationTime, (iii) lastModifiedTime, (iv) 설명[예컨대, <parameters> 서브리소스(420)의 텍스트 형식 설명], (v) allowedMethod, 및 (vi) contentType/dataType을 포함할 수 있다. allowedMethod는 <mgmtObj> 서브리소스(436)를 처리하는 허용된 RESTful 메소드(들)를 지정할 수 있다. contentType/dataType은 <mgmtObj> 서브리소스(436)의 유형을 지정할 수 있다.
게다가, 도 4a의 예에 나타낸 바와 같이, mgmtObjs(402)는 다른 <parameters> 서브리소스(432)를 <parameters> 서브리소스(420)에 종속시킴으로써 부가의 계층적 구조체를 가진다. 이 서브구조체(substructure)에서, <parameters> 서브리소스(420)는 다수의 <parameters> 서브리소스(432) 및 개별 <parameter> 리소스(434) 둘 다를 포함할 수 있다. 이러한 계층적 구조체는 다른 관리 트리를 mgmtObjs(402) 내로 임포트하는 것을 단순화하고 및/또는 트리 구조체 매핑을 수행하는 것을 단순화한다. 유의할 점은, 하나의 컨테이너(또는 그룹) 리소스가 다른 컨테이너(또는 그룹)를 그의 서브리소스로서 사용하여 contentInstance(또는 멤버)의 생성 및 사용을 가능하게 해주도록 되어 있지 않는 한, 이러한 계층적 구조체가 <mgmtObj> 서브리소스(406) 및 그의 자식 없이 (예컨대, 기존의 containers 또는 groups 리소스를 사용하여) 실현될 수 없다는 것이다.
<parameter> 리소스(434)는 (i) <parameter> 서브리소스(434)의 기본값을 포함, 유지 및/또는 저장할 수 있는 <defaultValue> 서브리소스(444); (ii) <parameter> 서브리소스(434)의 현재 값을 포함, 유지 및/또는 저장할 수 있는 <currentValue> 서브리소스(446); (iii) xREM을 위한 <accessRights> 서브리소스(448); (iv) <accessStatus> 서브리소스(450); 및 (v) <subscriptions> 서브리소스(444)를 포함할 수 있다. <accessRights> 서브리소스(448)는 REM을 수행하는 데 사용되는 서브리소스에 대한 허가의 표현을 포함, 유지 및/또는 저장할 수 있다. <accessRights> 서브리소스(448)는 그의 부모(있는 경우)로부터 상속될 수 있다.
<parameter> 리소스(434)는 다음과 같은 속성 (i) accessRightID, (ii) creationTime, (iii) lastModifiedTime, (iv) 설명[예컨대, <parameter> 리소스(434)의 텍스트 형식 설명], 및 allowedMethod를 포함할 수 있다. allowedMethod는 <parameter> 리소스(434)를 처리하는 허용된 RESTful 메소드(들)를 지정할 수 있다.
대안의 실시예에서, SCL을 mgmtObjs로 프로비저닝하기 위한 2-레벨 리소스 구조체 프레임워크(458)가 도 4b에 도시되어 있다. 리소스 구조체 프레임워크(458)는 mgmtObjs(460)를 포함할 수 있다. mgmtObjs(460)는, mgmtObjs(460)가 <parameters> 서브리소스(420)를 포함하지 않는 것을 제외하고는, 도 4a의 mgmtObjs(402)와 유사하다.
예시적인 M2M xREM 관리 모델
일 실시예에서, xREM은 클라이언트/서버(C/S) 모델 하에서 구현될 수 있다. 그에 부가하여 및/또는 다른 대안으로서, xREM은 M2M GW 배후에 있는 M2M 디바이스[D(34d) 및 D'(34e 내지 34) 등]를 관리하는 프록시 기능을 사용할 수 있다.
일 실시예에서, xREM 서버는 관리 제어기일 수 있다. xREM 서버는, 예를 들어, SNMP 관리자, OMA DM에 따른 DM 서버, 및 BBF-TR069에 따른 ACS 중 임의의 것으로서 동작하거나 그와 유사한 기능으로 동작할 수 있다. xREM 서버는 xREM 클라이언트 및 xREM 프록시와의 상호작용을 제어 및 관리할 수 있다.
일 실시예에서, xREM 클라이언트는 xREM 서버에 의해 제어되는 소프트웨어 엔터티일 수 있다. xREM 클라이언트는, 예를 들어, SNMP 에이전트, OMA DM에 따른 DM 클라이언트 및 BBF TR-069에 따른 CPE 중 임의의 것으로서 동작하거나 그와 유사한 기능으로 동작할 수 있다. xREM 서버 및 xREM 클라이언트는 함께 동작하여 관리 세션을 설정하고 관리 기능을 수행할 수 있다.
일 실시예에서, xREM 프록시는 xREM 클라이언트 및 xREM 서버 둘 다의 역할을 할 수 있다. xREM 프록시는 OMA DM 및/또는 BBF TR-069에 따라 동작하는 M2M 디바이스, 및/또는 SCL을 갖지 않는 M2M 디바이스 등의 D'-유형 디바이스를 관리하는 비xREM 관리 서버 기능을 가질 수 있다. xREM 프록시는 xREM 클라이언트와 xREM 서버(또는 비xREM 관리 서버) 간의 변환 및/또는 적응 기능을 포함할 수 있다. 예시적인 기능은 xREM 클라이언트와 xREM 서버 간의 변환, 및 xREM 클라이언트와 비xREM 관리 서버 간의 변환을 포함할 수 있다.
일 실시예에서, xREM은, 어디에 위치해 있느냐에 따라, xREM 서버(관리자), xREM 클라이언트(관리되는 엔터티), 또는 xREM 프록시(관리자 및 관리되는 엔터티 둘 다로서 역할함)일 수 있다.
도 5는 xREM을 수행하는 클라이언트-서버 모델(500)의 다이어그램을 나타낸 블록도이다. xREM은 ETSI TS 102 960에 따라 수행될 수 있다. 도 5를 참조하면, NREM(502)은 DREM(504) 및 GREM(506)의 xREM 클라이언트(각각, 504-1 및 506-1) 중 임의의 것 등의 하나 이상의 xREM 클라이언트 또는 GREM(510)의 xREM 프록시(510-1)와 통신 상호작용을 수행하는 xREM 서버(502-1)를 포함할 수 있다. NREM(502)은 제3자 관리 기관(512) 및 NREM(508) 등의 기타 NREM에 대한 개별적인 인터페이스를 가질 수 있다. GREM(510)은 xREM 클라이언트(510-2) 또는 xREM 프록시(510-1)로서 동작할 수 있다. M2M 게이트웨이가 M2M 서버에 의해 관리될 종단 디바이스로서 동작할 때, GREM(510)은 xREM 클라이언트로서 동작할 수 있다. M2M 게이트웨이가 M2M 게이트웨이 배후에 있는 M2M 디바이스(ETSI 호환 또는 비-ETSI)를 관리할 M2M 서버에 대한 프록시로서 동작할 때, GREM(510)은 xREM 프록시로서 동작한다. xREM 프록시(510-1)로서, GREM(510)은 xREM 클라이언트(510-2), xREM 서버(510-3), 비xREM 관리 서버(510-4), 및 프로토콜 변환 유닛(510-5)을 포함할 수 있다. DREM(512)은 xREM 클라이언트(512-1)를 포함할 수 있다. xREM 클라이언트(512-1)는 NREM(502) 내의 xREM 서버(502-1)와 또는, 다른 대안으로서, xREM 프록시(510-1) 내의 xREM 서버(510-3)와 상호작용할 수 있다.
OMA DM이 xREM을 구현하는 데 사용되는 경우, xREM 서버(502-1)는 DM 서버일 수 있고, xREM 클라이언트(512-1)는 DM 클라이언트일 수 있다. xREM 프록시(510-1)는 OMA GwMO일 수 있다. BBF TR-069가 xREM을 구현하는 데 사용되는 경우, xREM 서버(502-1)는 ACS일 수 있고, xREM 클라이언트(512-1)는 CPE일 수 있다. SNMP가 xREM을 구현하는 데 사용되는 경우, xREM 서버(502-1)는 SNMP 관리자일 수 있고, xREM 클라이언트(512-1)는 SNMP 에이전트일 수 있다. xREM 프록시(510-1)는 SNMP 프록시일 수 있다.
다수의 관리 프로토콜의 지원
일 실시예에 따르면, 시스템(10) 등의 통합된 M2M 시스템은 다수의 수직 M2M 응용 프로그램을 포함할 수 있고, 이 경우 상이한 관리 프로토콜이 배포될 수 있다. 예를 들어, 그의 xREM 클라이언트로서 DM 클라이언트를 지원하는 M2M 디바이스는 이동하여 BBF TR-069만을 지원하는 M2M GW에 또는 BBF TR-069 디바이스만을 관리해 온 M2M 서버에 연결될 수 있다. 대안으로서, 다른 적당한 OMA DM 디바이스 및 BBF TR- 069 디바이스는 본 명세서에서의 실시예에 따라 통합된 M2M 시스템에서 관리될 수 있다.
도 6은 다수의 상이한 관리 프로토콜을 사용하여 xREM을 지원하는 터널-기반 방식을 나타낸 블록도이다. NREM(602) 및/또는 GREM(604)은 상이한 M2M GW 및 디바이스와의 관리 상호작용을 위해 상이한 관리 프로토콜을 사용할 수 있다. 터널 모듈은 다음과 같은 것들을 수행할 수 있다. 터널 모듈은 D/GREM과 NREM 사이에서 및/또는 GREM과 DREM 사이에서 협상하여 어느 관리 프로토콜을 사용할지를 결정하기 위해 협상을 수행할 수 있다. 터널 모듈은 또한 이 결정에 따라 xREM 소프트웨어 업데이트를 수행할 수 있다.
터널 모듈은 xREM 데이터 모델과 OMA DM 관리 객체, BBF TR-069 관리 파라미터 및/또는 SNMP MIB 간에 변환하기 위해 데이터 모델 변환을 수행할 수 있다. 터널 모듈은 또한 OMA DM 명령(또는 BBF TR069 명령)과 xREM RESTful 메소드 간의 관리 명령 변환 및/또는 매핑을 수행할 수 있다. 터널 모듈은 또한 OMA DM, BBF TR-069 또는 SNMP 프로토콜을 중간 기준점에 걸쳐 RESTful 메소드를 사용할 수 있도록 적응시키기 위해 프로토콜 적응을 수행할 수 있다.
관리 프로토콜을 협상하거나 표시하는 방식
예를 들어, mgmtProtocolType이라고 하는 파라미터는 관리 프로토콜의 유형을 나타내는 데 사용될 수 있다. mgmtProtocolType은 M2M 디바이스, M2M 게이트웨이 또는 M2M 서버의 SCL일 수 있는 리소스 <scl>의 속성(또는 서브리소스)일 수 있다. 그에 부가하여, mgmtProtocolType은 구성 파라미터로서 M2M SCL 관리 객체("SCLMO"이라고 함)에 포함될 수 있다. 일 실시예에서, M2M 디바이스는 M2M 디바이스와 M2M 서버 사이에서 또는 M2M 디바이스와 M2M 게이트웨이 사이에서 사용할 관리 프로토콜 유형을 나타내기 위해 "mgmtProtocolType"을 사용할 수 있다. 일 실시예에서, M2M 게이트웨이는 M2M 게이트웨이와 M2M 서버 사이에서 사용되는 관리 프로토콜 유형을 나타내기 위해 "mgmtProtocolType"을 사용할 수 있다. 이것을 용이하게 해주기 위해, M2M 게이트웨이의 <scl>은 속성(또는 서브리소스) "mgmtProtocolType"을 포함할 수 있고, M2M 게이트웨이의 SCLMO는 파라미터 "mgmtProtocolType"을 포함할 수 있다. M2M 디바이스가 M2M 게이트웨이 배후에 존재하는 경우, 제2 속성(또는 서브리소스) "mgmtProtocolTypeExt"는 M2M 게이트웨이 배후에 있는 M2M 디바이스와 M2M 게이트웨이 사이의 관리 프로토콜 유형을 나타내는 데 사용될 수 있다.
일 실시예에서, M2M 서버는 M2M 디바이스 및/또는 M2M 게이트웨이를 관리하기 위해 그가 지원하는 관리 프로토콜 유형을 나타내기 위해 "mgmtProtocolType"을 사용할 수 있다. 이것을 용이하게 해주기 위해, M2M 서버의 <scl>은 속성(또는 서브리소스) "mgmtProtocolType"을 포함할 수 있다.
일 실시예에서, N-SCL(및/또는 G-SCL)은 대응하는 NREM 및/또는 GREM이 지원하는 다수의 관리 프로토콜의 목록을 나타내는 속성(또는 서브리소스) mgmtProtocolType을 포함할 수 있다.
대안으로서, mgmtProtocolType은 mgmtObjs 리소스의 속성 및/또는 각각의 <mgmtObj> 인스턴스의 속성으로서 부가될 수 있다. <scl>의 속성, mgmtObjs 리소스의 속성 또는 <mgmtObj>. 리소스의 속성으로서 mgmtProtocolType을 사용하여 DREM 및/또는 GREM("D/GREM")과 NREM 사이 및/또는 DREM과 GREM 사이의 관리 프로토콜을 협상하거나 나타내기 위해 이하의 방식이 적용될 수 있다.
도 7a 내지 도 7c는, 각각, REM을 위해 사용할 관리 프로토콜의 유형을 결정하는 예시적인 흐름(700, 730 및 760)을 나타낸 흐름도이다. 각각의 흐름(700, 730 및 760)은 편의상 도 1a 내지 도 1c의 시스템(10)을 참조하여 기술되어 있다. 흐름(700, 730 및 760)은 또한 다른 아키텍처를 사용하여 수행될 수도 있다.
D/ GREM 과 NREM 사이
방식 1 - " SCL 등록" 및/또는 " SCL 등록 업데이트 "에 mgmtProtocolType 을 피기백하기
이제 도 7a의 흐름(700)을 참조하면, D/GREM은 SCL 등록 프로세스(702)를 개시할 수 있고, 그 동안에 D/GREM은 하나 이상의 요청("SCL REGISTRATION REQUEST") 메시지를 M2M 서버(NREM)로 송신할 수 있다. SCL 등록 프로세스(702)의 일부로서, 그의 개시에 앞서 및/또는 그의 개시 이후에, D/GREM은 D/GREM이 지원하는 관리 프로토콜의 유형을 나타내는 값("mgmtProtocolType (value)")을 D/G-SCL의 "mgmtProtocolType" 속성/서브리소스로부터 획득할 수 있다.
M2M 디바이스/게이트웨이(D/GREM)는 이어서 SCL REGISTRATION REQUEST 메시지들 중 하나 이상을 선택하고 그의 파라미터인 mgmtProtocolType (value)으로 채우며, 이어서 이러한 SCL REGISTRATION REQUEST [mgmtProtocolType (value)] 메시지를 M2M 서버(NREM)로 송신한다(704). SCL REGISTRATION REQUEST [mgmtProtocolType (value)] 메시지(들)에 응답하여, M2M 서버(NREM)는 하나 이상의 응답("SCL REGISTRATION RESPONSE") 메시지를 선택하고 그의 파라미터인 수신된 mgmtProtocolType (value)으로 채운다. 그 후에, M2M 서버(NREM)는, mgmtProtocolType (value)의 수신 및/또는 수신된 mgmtProtocolType에 의해 표시되는 관리 프로토콜의 유형의 수락을 확인 응답하기 위해, 이러한 SCL REGISTRATION RESPONSE [mgmtProtocolType (value)] 메시지(들)를 M2M 디바이스/게이트웨이(D/GREM)로 송신할 수 있다(706). SCL 등록 프로세스(있는 경우)를 완료하기 위해 SCL REGISTRATION RESPONSE [mgmtProtocolType (value)] 메시지(들) 및 다른 메시지의 수신 후에, D/GREM은 SCL 등록 프로세스를 종료할 수 있다(708). 흐름(700)을 수행함으로써, D/GREM은 REM을 수행할 때 M2M 서버(NREM) 및 M2M 디바이스/게이트웨이(D/GREM)가 사용할 수 있는 관리 프로토콜의 유형의 통지 및/또는 수락을 용이하게 해주기 위해 SCL 등록 프로세스에 mgmtProtocolType 속성/서브리소스를 피기백할 수 있다.
비록 도시되어 있지 않지만, M2M 서버(NREM)는 N-SCL의 mgmtProtocolType 속성/서브리소스에 의해 지정된 또는 다른 방식으로 표시된 관리 프로토콜의 유형을 사용하라고 M2M 디바이스/게이트웨이(D/GREM)에 지시하기 위해, 요청받는 일 없이, SCL 등록 프로세스에 mgmtProtocolType 속성/서브리소스를 피기백할 수 있다. M2M 서버(NREM)는, 예를 들어, N-SCL의 mgmtProtocolType 속성/서브리소스로부터 mgmtProtocolType (value)을 검색하고, 하나 이상의 SCL REGISTRATION RESPONSE 메시지(들)를 그의 파라미터인 mgmtProtocolType (value)으로 채우며, 채워진 SCL REGISTRATION RESPONSE [mgmtProtocolType (value)] 메시지(들)를 M2M 디바이스/게이트웨이(D/GREM)로 송신할 수 있다.
대안으로서, M2M 서버(NREM) 및 M2M 디바이스/게이트웨이(D/GREM)는, M2M 서버(NREM) 또는 M2M 디바이스/게이트웨이(D/GREM)가 그가 수신한 mgmtProtocolType (value)을 상대방으로 송신할 때까지, 각자의 mgmtProtocolType (values)으로 채워져 있는 SCL REGISTRATION REQUEST 메시지 및 SCL REGISTRATION RESPONSE 메시지를 교환함으로써 사용할 관리 프로토콜의 유형을 협상할 수 있다.
도 7b 및 도 7c에서, SCL 등록 업데이트에 mgmtProtocolType을 피기백하는 프로세스는 다음과 같다:
SCL 등록 업데이트 프로세스 동안, M2M 서버(NREM)는 "mgmtProtocolType"을 M2M 디바이스/게이트웨이(D/GREM)로 송신되는 메시지에 피기백함으로써 M2M 디바이스/게이트웨이(D/GREM)에 의해 사용될 "mgmtProtocolType"을 지정할 수 있다.
다른 대안으로서, "SCL 등록 업데이트"의 프로세스 동안, M2M 디바이스/게이트웨이(D/GREM)는 M2M 서버(NREM)로 송신되는 메시지에 "mgmtProtocolType"을 피기백함으로써 그의 "mgmtProtocolType"을 M2M 서버(NREM)에 보고할 수 있다.
방식 2 - " mgmtObj 리소스 생성하기"에 mgmtProtocolType 를 피기백하기
ETSI M2M 기능적 아키텍처는 관리 객체 리소스를 생성하는 이하의 절차를 정의한다. 그 결과, mgmtProtocolType은 M2M 디바이스/게이트웨이(D/GREM)가 그의 mgmtProtocolType을 M2M 서버(NREM)에 알려줄 수 있도록 그 절차에 삽입될 수 있다.
도 8에 도시된 바와 같이, mgmtObj 리소스 생성하기에 mgmtProtocolType을 피기백하는 프로세스는 다음과 같다:
이 프로세스가 M2M 디바이스/게이트웨이(D/GREM)에 의해 개시되면, M2M 디바이스/게이트웨이(D/GREM)는 이 프로세스 동안 요청 메시지를 M2M 서버(NREM)로 송신할 것이다. M2M 디바이스/게이트웨이(D/GREM)는 이 요청 메시지에 파라미터로서 "mgmtProtocolType"을 피기백할 수 있다.
방식 3 - " mgmtProtocolType "을 송신하는 새로운 절차를 생성하기
방식 2 및 방식 3에 기술된 바와 같이 기존의 M2M 절차에 "mgmtProtocolType"을 피기백하는 대신에, 이하의 절차는 M2M 서버(NREM)와 M2M 디바이스/게이트웨이(D/GREM) 사이에서 "mgmtProtocolType"을 송신하는 프로세스를 정의한다. 도 9에 도시된 바와 같이, 이 프로세스는 다음과 같다:
" mgmtProtocolType " 업데이트
M2M 디바이스/게이트웨이(D/GREM)는 "mgmtProtocolType"을 업데이트하기 위해 <scl-of- server>/scls/<scl-dg>/mgmtProtocolType으로 어드레싱되는 Update 메시지를 송신한다.
<scl-of-server>는 M2M 서버를 나타낸다. <scl-dg>는 그의 mgmtProtocolType의 M2M 서버를 업데이트하는 M2M 디바이스/게이트웨이(D/GREM)를 나타낸다. "mgmtProtocolType"은 <scl-dg>의 새로운 속성일 수 있다. 그 결과, M2M 서버(NREM)는 M2M 서버에 등록되는 M2M 디바이스/게이트웨이(D/GREM)의 "mgmtProtocolType"을 알고 있다.
NREM은 또한, 도 10에 도시된 바와 같이, M2M 디바이스/게이트웨이의 "mgmtProtocolType"을 변경하기 위해 <scl-dg>/mgmtProtocolType으로 어드레싱되는 Update 메시지를 능동적으로 송신할 수 있다.
대안으로서, NREM은 M2M 디바이스/게이트웨이에서 사용되는 현재의 관리 프로토콜을 검색하기 위해 <scl-dg>/mgmtProtocolType으로 어드레싱되는 Retrieve 메시지를 송신할 수 있다.
방식 4 - SCL 발견에 mgmtProtocolType 을 피기백하기
mgmtProtocolType은 또한 다음과 같은 방식을 사용하여 SCL 발견을 위한 메시지에 피기백될 수 있다. 도 11에 도시된 바와 같이, M2M 디바이스/게이트웨이(D/GREM)가 M2M 서버(NSCL)을 발견하라는 요청 메시지를 발행할 때, M2M 디바이스/게이트웨이는 그의 mgmtProtocolType을 요청 메시지에 포함시킬 것이다. 피기백된 mgmtProtocolType 정보는 mgmtProtocolType에 의해 표시되는 바와 같이 관리 프로토콜을 지원하지 않는 M2M 서버를 필터링 제거하는 데 도움을 줄 수 있다.
M2M 서버의 mgmtProtocolType은 M2M 디바이스/게이트웨이로의 SCL 발견 응답 메시지에 피기백될 수 있다. 피기백된 mgmtProtocolType은 M2M 디바이스/게이트웨이가 적절한 M2M 서버를 선택하는 데 도움을 줄 수 있다. M2M 디바이스/게이트웨이는 또한 피기백된 mgmtProtocolType에 의해 표시된 바와 같은 관리 프로토콜을 사용하도록 변경될 수 있다.
DREM 과 GREM 사이
이 경우에, M2M 디바이스는 프록시인 M2M 게이트웨이 배후에 있다. 그 결과, M2M 디바이스는 그의 mgmtProtocolType을 M2M 게이트웨이에 알려줄 필요가 있거나, M2M 게이트웨이는 M2M 디바이스의 mgmtProtocolType을 능동적으로 검색할 수 있다. 상기 경우 1에 대한 유사한 방식이 이용될 수 있다.
방식 1 - " SCL 등록" 및 " SCL 등록 업데이트 "에서의 피기백 mgmtProtocolType
ETSI M2M 기능적 아키텍처는 SCL 관리를 위한 이하의 절차를 정의하고, 그 결과, DREM이 그의 mgmtProtocolType을 GREM에 알려줄 수 있도록, mgmtProtocolType이 그 절차에 삽입될 수 있다.
SCL 등록:
이 프로세스 동안, DSCL은 다수의 요청 메시지를 NSCL로 송신할 것이다. DREM은 "mgmtProtocolType"을 파라미터로서 그 요청 메시지들 중 임의의 것에 피기백할 수 있다. 그에 부가하여, GREM은 "mgmtProtocolType"에 의해 지정된 바와 같은 관리 프로토콜을 사용하라고 DREM에 지시하기 위해 "mgmtProtocolType"을 DREM에의 응답 메시지에 피기백할 수 있다.
SCL 등록 업데이트하기
"SCL 등록 업데이트"의 프로세스 동안, GREM은 DREM으로 송신되는 메시지에 mgmtProtocolType을 피기백함으로써 DREM에 의해 사용될 "mgmtProtocolType"을 지정할 수 있다. "SCL 등록 업데이트"의 프로세스 동안, DREM은 GREM으로 송신되는 메시지에 "mgmtProtocolType"을 피기백함으로써 그의 "mgmtProtocolType"을 GREM에 보고할 수 있다.
방식 2 - " mgmtObj 리소스 생성하기"에 mgmtProtocolType 를 피기백하기
ETSI M2M 기능적 아키텍처는 관리 객체 리소스를 생성하는 이하의 절차를 정의한다. 그 결과, DREM이 그의 mgmtProtocolType을 GREM에 알려줄 수 있도록, mgmtProtocolType이 그 절차에 삽입될 수 있다.
mgmtObj 리소스 생성하기:
이 프로세스가 DSCL(DREM)에 의해 개시되면, DSCL은 요청 메시지를 NGSCL로 송신할 것이다. 이 프로세스 동안, DREM은 "mgmtProtocolType"을 파라미터로서 이 요청 메시지에 피기백할 수 있다.
방식 3 - " mgmtProtocolType "을 송신하는 새로운 절차를 생성하기
방식 2 및 방식 3에 기술된 바와 같이 기존의 M2M 절차에 "mgmtProtocolType"을 피기백하는 대신에, 이하의 절차는 또한 GREM과 DREM 사이에서 "mgmtProtocolType"을 송신하는 데 이용될 수 있다.
" mgmtProtocolType " 업데이트
M2M 디바이스(DREM)는 "mgmtProtocolType"을 업데이트하기 위해 <scl-of-gw>/scls/<scl-d>/mgmtProtocolType으로 어드레싱되는 Update 메시지를 송신한다. <scl-of-gw>는 M2M 게이트웨이를 나타낸다. <scl-d>는 M2M 게이트웨이에 등록되는 M2M 디바이스를 나타내고, 그의 mgmtProtocolType의 M2M 게이트웨이를 업데이트한다. "mgmtProtocolType"은 <scl-d>의 속성이다. 그 결과, M2M 게이트웨이(GREM)는 M2M 게이트웨이에 등록되는 M2M 디바이스(DREM)의 "mgmtProtocolType"을 알고 있다.
M2M 게이트웨이(GREM)는 또한 M2M 디바이스의 "mgmtProtocolType"을 변경하기 위해 <scl-d>/mgmtProtocolType으로 어드레싱되는 Update 메시지를 능동적으로 송신한다.
" mgmtProtocolType " 검색하기
M2M 게이트웨이(GREM)는 M2M 디바이스에서 사용되는 현재의 관리 프로토콜을 검색하기 위해 <scl-dg>/mgmtProtocolType으로 어드레싱되는 Retrieve 메시지를 송신한다.
방식 4 - SCL 발견에 mgmtProtocolType 을 피기백하기
mgmtProtocolType은 또한 다음과 같은 방식을 사용하여 SCL 발견을 위한 메시지에 피기백될 수 있다.
M2M 디바이스(DREM)가 M2M 게이트웨이(GSCL)을 발견하라는 요청 메시지를 발행할 때, M2M 디바이스는 그의 mgmtProtocolType을 요청 메시지에 포함시킬 것이다. 피기백된 mgmtProtocolType 정보는 mgmtProtocolType에 의해 표시되는 바와 같이 관리 프로토콜을 지원하지 않는 M2M 게이트웨이를 필터링 제거하는 데 도움을 줄 수 있다.
M2M 게이트웨이의 mgmtProtocolType은 M2M 디바이스로의 SCL 발견 응답 메시지에 피기백될 수 있다. 피기백된 mgmtProtocolType은 M2M 디바이스가 적절한 M2M 게이트웨이를 선택하는 데 도움을 줄 수 있다. M2M 디바이스는 또한 피기백된 mgmtProtocolType에 의해 표시된 바와 같은 관리 프로토콜을 사용하도록 변경될 수 있다.
모든 액세스 이력에 대한 예시적인 리소스 정의
원격 엔터티 관리를 위해, 요청자/발행자-SCL이 수신기-SCL의 모든 로컬 리소스에 대해 가지고 있던 모든 액세스 이력을 수신기-SCL이 로깅하는 것이 중요할 수 있다. 현재의 ETSI M2M 기능적 아키텍처가 리소스 accessStatus를 정의하지만, 이는, 과거에 있었던 리소스에 대한 모든 동작이 아니라, 마지막 액세스(검색/업데이트/가입)만을 기록하고 있다. 모든 액세스 이력을 저장하는 것을 용이하게 해주기 위해, 본 개시 내용에서 accessHistories라고 하는 새로운 리소스가 정의된다. accessHistories에 대한 관련 동작도 역시 정의된다.
리소스 accessHistories
accessStatus에 기초하여, 리소스 accessHistories의 예시적인 구조체를 나타내고 있는 도 12의 예에서와 같이 accessHistory가 정의되고 예시될 수 있다. 도 12를 참조하면, accessHistories는 다음과 같은 컴포넌트를 포함할 수 있다:
- "attribute"은 accessRightID를 가질 수 있다
- status: 액세스 이력을 로깅하기 시작하는지 로깅하는 것을 중단하는지를 나타내는 데 사용됨
- <accessInstance>: 액세스 인스턴스의 수
각각의 <accessInstance>는 그에 관한 액세스 상세를 기록하기 위해 다음과 같은 서브리소스를 가질 수 있다:
- method: 이 액세스에 관여된 메소드. 이는 Create, Retrieve, Update, Delete, Subscription, 또는 Announce일 수 있다.
- requestorID: 이 액세스를 요청하는 엔터티의 ID
- resourceURI: 이 액세스가 동작해야만 하는 리소스의 URI
- timeStamp: 이 액세스가 일어나는 시각
- sequenceNumber: 액세스 시퀀스를 나타내는 자동 증분 정수
- result: 이 동작의 결과
o 메소드가 Update이면, 이는 resourceURI의 새로운 값을 나타낸다
o 이는 다른 메소드에 대해 Success 또는 Failure일 수 있다. 여기서 장애 관리를 위해 상이한 유형의 Failure를 정의하는 것이 가능하다.
리소스 accessHistories는 M2M 디바이스 및 GW에 저장될 수 있다. 디바이스/GW에 있는 로컬 리소스에 대한 동작이 있을 때마다, accessInstance가 자동으로 생성되고 accessHistories에 부가될 수 있다. 리소스로서, 관리를 위해 많은 경우에 NREM에 의해 accessHistories가 액세스될 수 있다. 환언하면, NREM은 D/GREM에 대한 accessHistories를 생성/검색/업데이트/삭제할 수 있다. 다음과 같은 기능이 구현될 수 있다:
- 생성: NREM은 특정의 시간 구간 동안 또는 영구히 특정의 "method" 및/또는 "resourceURI"에 대한 accessHistories를 생성하라고 D/GREM에 요청한다.
- 검색: NREM은 D/GREM으로부터 모든 또는 일부 <accessInstance>를 검색한다.
- 업데이트: NREM은 "status"의 값을 변경함으로써 액세스 이력 함수를 디스에이블하거나 재개하라고 D/GREM에 요청한다.
- 삭제: NREM은 모든 또는 일부 <accessInstance>를 삭제하라고 D/GREM에 요청한다.
도 12에 도시된 <accessInstance>는 플랫 구조체로서, 도 13에 도시된 바와 같이 "method"에 기초하여 및/또는 도 14에 도시된 바와 같이, "requestorID"에 기초하여 재구성되어, 각각, 2-레벨 및 3-레벨 계층적 구조체를 형성할 수 있다. 도 13은 "method"에 기초하여 구성된 리소스 accessHistories에 대한 예시적인 구조체를 나타낸 것이다. 도 14는 "method" 및 "requestorID"에 기초하여 구성된 리소스 accessHistories에 대한 예시적인 구조체를 나타낸 것이다. 이러한 계층적 구조체는 리소스 accessHistories에 대한 질의/검색 동작을 촉진시키는 데 유용할 수 있고, 리소스 제약된 M2M 디바이스에서 특히 그렇다.
xREM 에 대한 관리 권한 위임에 대한 예시적인 호출 흐름
M2M 디바이스 및/또는 GW의 관리 권한이 다른 M2M 서버로 위임될 수 있다. M2M 디바이스의 관리 권한이 다른 M2M GW로도 위임될 수 있다. 본 개시 내용의 실시예에 따르면, M2M 디바이스 및 GW에 대한 관리 권한 위임 절차가 본 명세서에 기술되어 있다.
관리 권한 위임
위임자에 의해 개시된 위임
도 15는 관리 권한 위임(위임자에 의해 개시됨)을 위한 절차의 메시지 흐름도를 나타낸 것이다. 도 15를 참조하면, N-SCL-1은 D/G-SCL을 다른 N-SCL에 위임한다. N-SCL 1은 D/G-SCL이 온라인으로 된 후에 D/G-SCL에 대해 "위임 준비(Delegation Preparation)"를 발행한다. "위임 준비"는 진행 중인 위임 동작에 대한 준비를 하라고 D/G-SCL에 지시하는 데 사용될 수 있다. D/G-SCL은 "위임 응답(Delegation Response)"을 N-SCL 1로 다시 송신할 수 있다. D/G는 그 후에 온라인으로 있을 수 있다. N-SCL 1은 D/G SCL에 대한 새로운 관리 기관으로서 선택된 N-SCL X에 대해 "위임 요청(Delegation Request)"을 발행할 수 있다. "위임 요청"은 다음과 같은 정보를 포함하고 있을 수 있다:
o 위임될 D/G-SCL의 URI 및/또는 인증-관련 정보
o 관리 위임을 요청하는 이유
N-SCL X는 "위임 요청"에 대해 YES 또는 NO를 답변함으로써 "위임 응답(Delegation Response)"을 N-SCL 1로 다시 송신할 수 있다. N-SCL 1은, 위임을 수락하기로 합의하는 N-SCL을 찾을 때까지 또는 최대 횟수만큼 시도한 후에, "위임 요청"을 다른 N-SCL로 반복하여 송신할 수 있다.
N-SCL 1은 D/G-SCL에 대해 "위임 통보(Delegation Inform)"를 발행할 수 있다. N-SCL X 중 어느 것도 합의하지 않는 경우, N- SCL 1은 이 메시지를 사용하여 진행 중인 위임을 취소한 것을 D/G-SCL에 통보할 수 있다. 이어서, D/G는 보통 때와 같이 동작할 수 있다. 이는 계속 슬립 상태로 갈 수 있다. 이어서, 위임 프로세스 전체가 중단될 수 있다. 그렇지 않은 경우, "위임 통보"는 위임을 수락하기로 합의하는 N-SCL X에 관한 정보를 포함할 것이다. D/G-SCL은 "위임 응답"을 다시 송신할 수 있다.
N-SCL 1은 N-SCL X에 위임 동작을 수행하라고 트리거하기 위해 그에 대해 "위임 시작(Delegation Start)"을 발행한다.
N-SCL X는 D/G-SCL에 대해 "위임 실행(Delegation Execution)"을 발행할 수 있다. D/G-SCL은 N-SCL X에 대해 인증을 수행할 수 있다.
D/G-SCL은 "위임 응답"을 N-SCL X로 다시 송신할 수 있다. D/G SCL은 N-SCL X를 그의 새로운 관리 기관으로 설정함으로써 그의 관리 객체를 업데이트할 수 있다. N-SCL X는 D/G-SCL을 그의 권한 하에서 관리되는 엔터티로서 포함시킴으로서 그의 관리 객체를 업데이트할 수 있다.
N-SCL X는 N-SCL 1에 대해 "위임 종료(Delegation Finish)"를 발행할 수 있다.
N-SCL 1은 "위임 ACK(Delegation ACK)"를 N-SCL X로 다시 송신할 수 있다.
N-SCL 1은 D/G-SCL을 그의 관리 기관으로부터 제거함으로써 그의 관리 객체를 업데이트할 수 있다.
N-SCL 1은 관리 권한을 위임하는 엔터티로서 N-SCL X를 부가함으로써 그의 관리 객체를 업데이트할 수 있다.
N-SCL X는 관리 권한을 위임받은 엔터티로서 N-SCL 1을 부가함으로써 그의 관리 객체를 업데이트할 수 있다.
디바이스에 의해 개시된 위임
도 16은 관리 권한 위임(디바이스에 의해 개시됨)을 위한 예시적인 메시지 흐름도를 나타낸 것이다. D/G가 관리 권한 위임을 능동적으로 요청하는 시나리오에서 이것이 적용될 수 있다. 위임자-개시 위임과의 유일한 차이점은 처음 2개의 단계이다. 도 16을 참조하면, D/G-SCL은 N-SCL 1에 대해 "위임 요청"을 발행한다. D/G- SCL은 이 메시지에 위임을 요청한 이유를 나타낼 수 있다. N-SCL 1은 위임을 수행하겠다는 의지를 D/G-SCL에 통보함으로써 "위임 응답"을 D/G-SCL로 다시 송신할 수 있다. N-SCL 1은 위임을 수행하는 것을 거부할 수 있다. 이어서, 위임 프로세스 전체가 중단될 수 있다.
도 16과 달리 그리고 다른 대안으로서, D/G는 "위임 요청"을 수증자(새로운 관리 기관)로 직접 송신할 수 있다. 이어서, 수증자는 승인을 위해 위임자에 요청할 수 있다. 예시적인 상세한 절차가 관리 권한 위임(수증자에게 직접, 디바이스에 의해 개시됨)의 예시적인 메시지 흐름도를 나타낸 도 17에 도시되어 있다. 시나리오는 위임자가 이전에 디바이스에 대한 어떤 잠재적인 수증자를 구성하는 것을 필요로 할 수 있고, 디바이스와 위임자 사이의 통신이 문제점에 봉착할 때 일어날 수 있다.
수증자-개시 위임
위임자-개시 및 디바이스-개시 위임에 부가하여, 관리 권한 위임이 또한 선택적으로 수증자에 의해 개시될 수 있다. 예를 들어, 도 18은 관리 권한 위임(수증자에 의해 개시됨)을 위한 예시적인 메시지 흐름도를 나타낸 것이다. 도 18을 참조하면, N-SCL X는 N-SCL 1에 위임을 요청할 수 있다. N-SCL 1은 D/G-SCL로부터 N-SCL X로 관리 권한을 위임하도록 승인할 수 있다. 각각의 단계의 의미는 도 16과 관련하여 기술된 것과 유사하다.
프록시 역할을 하는 게이트웨이 하에서의 위임
일부 장치가 게이트웨이 배후에 있는 시나리오에 대해, 관리 권한 위임이 프록시로서의 게이트웨이를 통해 수행될 수 있다. 예를 들어, 도 19는 관리 권한 위임(게이트웨이가 프록시 역할을 함)을 위한 예시적인 메시지 흐름도를 나타낸 것이다. 도 19를 참조하면, N-SCL-1은 프록시로서의 G-SCL을 통해 D-SCL을 N-SCL X에 위임할 수 있다. G-SCL은 위임 통합(delegation aggregation)을 능동적으로 수행한다. 기본적으로, G-SCL은, 그의 배후에 있는 D 또는 D'을 위해, 도 16에서의 유사한 절차를 사용하여 N-SCL 1 및 N-SCL X로 관리 권한 위임을 수행할 수 있다. D 또는 D'이 온라인으로 될 때, G-SCL은 위임 결과, 즉 새로운 관리 기관 N-SCL X를 이들에게 통지할 것이다.
디바이스와 게이트웨이 간의 위임
일 실시예에서, D-SCL의 관리 권한은 G-SCL 1으로부터 G-SCL X로 위임된다. 예를 들어, 도 20은 관리 권한 위임(디바이스와 게이트웨이 간의 위임)을 위한 예시적인 메시지 흐름도를 나타낸 것이다. 도 20을 참조하면, D-SCL, G-SCL 1 및 G-SCL X 간의 위임 프로세스 후에, G-SCL 1은 통지 결과를 N-SCL 1에 통지할 수 있다.
계층적 SCL 구조체
도 21은 일반적인 시나리오의 다이어그램을 나타낸 것으로서, 여기서 1) 모든 SCL의 관리 권한 관계는 계층적 구조체를 형성하고; 2) SCL 4는 SCL 9에 대한 그의 관리 권한을 SCL 3로 위임하고자 한다. 이는 기본적으로 3가지 단계를 따른다:
- 단계 1: SCL 4는 SCL 2 및 SCL 1을 통해 홉별로, 궁극적으로 SCL 3으로 "위임 요청"을 발행한다.
- 단계 2: SCL 3는 "위임 응답"을 다시 SCL 4로 송신한다.
- 단계 3: SCL 4는 "위임 통보"를 SCL 9에 발행한다.
- 단계 4: SCL 3 및 SCL 9는 "위임 실행" 관련 상호작용을 수행한다.
- 단계 5: SCL 3은 SCL 1 및 SCL 1을 통해 홉별로, SCL 3으로 "위임 통지"를 궁극적으로 송신한다.
o SCL 1, SCL 2 및 SCL 4는 이 관리 권한 변경을 반영하기 위해 그에 따라 그의 관리 객체를 업데이트할 수 있다.
예시적인 xREM 권한 위임
NREM은 DREM 및 GREM을 관리하는 일을 맡고 있다. 그렇지만, ETSI xREM은 원격 엔터티 관리(xREM) 권한은 물론 xREM 권한 위임의 개념도 기술하고 있지 않다. M2M 디바이스 또는 GW의 xREM 권한은, M2M 서버 교체, 부하 분산 및 이동성 등의 이유로, M2M 서버로부터 다른 M2M 서버로 위임될 필요가 있다. M2M 디바이스가 M2M GW 배후에 있는 경우, 심지어 M2M 디바이스의 xREM 권한이 M2M 서버로부터 M2M GW로 위임될 수 있고, 그 반대일 수 있다.
OMA-DM이 클라이언트 권한 위임에 대한 상위 레벨 절차를 정의하지만, 이는 중간에 있는 슬립 상태의 디바이스 또는 M2M GW를 고려하지 않는다. 그 결과, 이는 ETSI M2M xREM에 대해 직접 적용될 수 없다. ETSI M2M xREM은 그 자신의 xREM 권한 위임을 가질 필요가 있다.
M2M 디바이스 또는 GW가 M2M 서버에 성공적으로 등록될 때, M2M 서버는 기본적으로 M2M 디바이스/GW에 대한 xREM 권한을 가진다. M2M 디바이스가 M2M GW 배후에 있을 때, GW는 그 M2M 디바이스에 대한 xREM 권한을 가진다. 따라서, xREM 권한 위임은 상이한 시나리오를 의미할 수 있다:
경우 1: M2M 서버는 그의 xREM 권한을 다른 M2M 서버로 위임한다
경우 2: M2M 서버는 그의 xREM 권한을 M2M GW로 위임한다
경우 3: M2M GW는 그의 xREM 권한을 M2M 서버로 위임한다
경우 4: M2M GW는 그의 xREM 권한을 다른 M2M GW로 위임한다
xREM 을 위한 예시적인 기능
그 결과, ETSI M2M xREM은 xREM 권한 위임을 지원하기 위해 새로운 기능을 가질 필요가 있다. 네트워크 원격 엔터티 관리(Network Remote Entity Management, NREM)는 다음과 같은 기능을 가질 필요가 있다: xREM 권한 위임을 지원한다. NREM은 M2M 디바이스 및 M2M 게이트웨이에 대한 xREM 권한을 가진다. NREM은 xREM 권한 위임을 지원하기 위해 다음과 같은 기능을 가질 필요가 있다: M2M 디바이스 및 M2M 게이트웨이에 대한 그의 xREM 권한을 다른 M2M 서버로 위임하거나 M2M 디바이스에 대한 그의 xREM 권한을 M2M 게이트웨이로 위임한다. 다른 M2M 서버 또는 M2M 게이트웨이로부터 요청된 xREM 권한 위임을 처리한다. 게이트웨이 원격 엔터티 관리(Gateway Remote Entity Management, GREM)는 다음과 같은 기능을 가질 필요가 있다: 관리되는 M2M 영역 네트워크의 M2M 디바이스에 대한 원격 관리 프록시로서 기능할 때.
xREM 권한 위임을 지원한다. M2M 디바이스가 M2M 게이트웨이 배후에 있을 때, M2M 게이트웨이는 그 M2M 디바이스에 대한 xREM 권한을 가진다. xREM 권한 위임을 지원하기 위해, M2M 게이트웨이는 다음과 같은 기능을 가질 필요가 있다: M2M 디바이스에 대한 그의 xREM 권한을 M2M 서버로 또는 다른 M2M 게이트웨이로 위임한다; 다른 M2M 서버 또는 M2M 게이트웨이로부터의 xREM 권한 위임 메시지를 처리한다; xREM 권한 위임을 지원한다. M2M 서버는 M2M 게이트웨이에 대한 xREM 권한을 가진다.
M2M 게이트웨이는 다음과 같은 기능을 가질 필요가 있다: M2M 게이트웨이에 대한 그의 xREM 권한을 다른 M2M 서버로 위임하라고 M2M 서버에 능동적으로 요청한다; M2M 서버로부터의 xREM 권한 위임 메시지를 수동적으로 처리한다.
디바이스 원격 엔터티 관리(Device Remote Entity Management, DREM)는 다음과 같은 기능을 가질 필요가 있다: xREM 권한 위임을 지원한다. M2M 서버는 M2M 디바이스에 대한 xREM 권한을 가진다.
M2M 디바이스는 다음과 같은 기능을 가질 필요가 있다: M2M 디바이스에 대한 그의 xREM 권한을 다른 M2M 서버로 위임하라고 M2M 서버에 능동적으로 요청한다; M2M 서버로부터의 xREM 권한 위임 메시지를 수동적으로 처리한다.
예시적인 비 RESTful 관리 명령 지원
비RESTful 관리 명령이 RESTful 방식으로 표현되고 실현될 수 있는 M2M xREM에 대한 시스템, 장치 및 방법의 실시예가 본 명세서에 제공되어 있다. 이러한 비RESTful 관리 명령의 예는 디바이스를 재부팅하는 재부팅(reboot) 명령; 다운로드 명령의 수신자에게 파일을 다운로드하라고 지시하는 다운로드(download) 명령; 특정의 프로세스를 실행하는 실행(execute) 명령; 리소스를 한 장소로부터 다른 장소로 복제 및/또는 이동하는 복사(copy) 명령 중 임의의 것을 포함할 수 있다. 재부팅 및 다운로드 명령은, 예를 들어, BBF-TR069에 따라 정의될 수 있다. 실행 및 복사 명령은, 각각, 예를 들어, OMA-DM의 "Exec" 명령 및 OMA-DM의 "Copy" 명령일 수 있다. 비RESTful 관리 명령은 또한, 예를 들어, 제어가능 요소(예컨대, 작동기)를 갖추고 있는 M2M 디바이스의 이러한 제어가능 요소를 제어하는 데 사용되는 하나 이상의 명령 등의 다른 명령을 포함할 수 있다.
하나 이상의 실시예에서, 리소스(resource) 명령이라고 하는 리소스가 비RESTful 관리 명령을 표현하기 위해 그리고 비RESTful 관리 명령의 실행("명령 실행")을 명령의 하나 이상의 발행자에 의해 지정된 상이한 방식으로 지원하기 위해 사용될 수 있다. 리소스 commands는 RESTful 메소드들 중 임의의 것을 사용하여 장치에서 비RESTful 관리 명령의 발행 및 명령 실행을 용이하게 해주기 위해 사용될 수 있다.
게다가, 리소스 commands는, 비RESTful 관리 명령들 중 임의의 것에 대해, 즉각 명령 실행, (예컨대, 랜덤한) 지연 후의 명령 실행, 단일 명령 실행(예컨대, 1회 명령 실행) 및/또는 다중 반복 명령 실행을 용이하게 해주기 위해 사용될 수 있다.
도 22a를 참조하면, 블록도는 리소스 commands를 나타내는 데이터 구조체의 인스턴스("<commandInstance>")를 가지는 <sclbase>의 예시적인 데이터 구조체를 나타내고 있다. <commandInstance>는 도 22a에 도시된 것과 같은 다수의 데이터 구조체 요소를 포함할 수 있다. 도시된 이들 데이터 구조체 요소 중에는, 속성을 나타내는 데이터 구조체 요소(" "attribute" ") 및 서브리소스 execMode, execParameters, execStartTime, execDuration, execResult, execStatus, requestorID 및 actorID를 나타내는 데이터 구조체 요소가 있다. "attribute"는, 앞서 논의된 것과 같은 accessRightID를 포함할 수 있다.
execMode는 <commandInstance>의 비RESTful 관리 명령의 특정의 명령 실행 모드를 지정하는 데 사용될 수 있다. execMode 데이터 구조체 요소는 명령 실행에 대한 모드("명령 실행 모드")를 나타내는 하나 이상의 항목을 포함할 수 있다. 명령 실행 모드의 예는 Immediate Once(즉각 1회) 모드; Immediate and Repeatedly(즉각 반복) 모드; Random Once(랜덤 1회) 모드 및 Random and Repeatedly(랜덤 반복) 모드 중 임의의 것을 포함할 수 있다.
Immediate Once 모드는 명령 실행이 즉각적으로 1회만 일어나야 한다는 것을 명시한다. Immediate and Repeatedly 모드는 명령 실행이 즉각적으로 반복하여 일어나야 한다는 것을 명시한다. 임의의 2개의 명령 실행 사이의 임의의 시간 간격은 execParameters에 명시되어 있을 수 있다. Random Once 모드는 명령 실행이 (예컨대, 랜덤한) 지연 후에 1회만 일어나야 한다는 것을 명시한다. 지연은 execParameters에 명시되어 있을 수 있다. Random and Repeatedly 모드는 명령 실행이 (예컨대, 랜덤한) 지연 후에 반복하여 일어나야 한다는 것을 명시한다. 임의의 2개의 명령 실행 사이의 지연 및 임의의 간격은 execParameters에 명시되어 있을 수 있다.
execParameters는 컨테이너일 수 있고, 명령 실행 모드와 연관되어 있는 정보를 포함할 수 있다. 앞서 살펴본 정보에 부가하여, 이 정보는 (1) Random Once 모드 및 Random Repeatedly 모드에서 명령 실행보다 특정 시간 이전에 어떻게 백오프할지를 명시하고 및/또는 (2) "Immediate and Repeatedly" 모드에서 그리고 "Random and Repeatedly" 모드에서 반복된 명령 실행에 대한 빈도수를 명시하는 것에 대한 정보를 포함할 수 있다.
execStartTime은 실제의 마지막 명령 실행 시각을 명시할 수 있다. execDuration은 계속된 명령 실행을 위해 필요한 지속기간을 명시할 수 있다. execResult는 마지막 명령 실행에 대한 반환된 값을 명시할 수 있다. execStatus는 명령 실행의 현재 상태를 명시할 수 있다. 이 상태는, 예를 들어, 완료됨(finished)(성공 또는 실패), 보류 중(pending), 동작 중(in-operation) 등일 수 있다. requestorID는 호출될 명령 실행을 요청하는 요청자의 ID(예컨대, URI)를 명시할 수 있다. actorID는 명령 실행을 호출하는 수신기의 ID(예컨대, URI)를 명시할 수 있다.
도 22b는 commands 리소스를 나타내는 예시적인 데이터 구조체("commands 리소스 구조체")를 나타낸 블록도이다. commands 리소스 구조체 도 22b에 도시된 것과 같은 다수의 데이터 구조체 요소를 포함할 수 있다. 이 commands 리소스 구조체의 데이터 구조체 요소들 중 다수는 도 22a의 commands 리소스 구조체와 유사하다. 이들 데이터 구조체 요소 중에는 속성을 정의하는 데이터 구조체 요소("commands 리소스 "attribute" ") 및 각자의 명령 모음을 나타내는 데이터 구조체 요소의 세트("<command>")가 있다. <command>의 각각의 인스턴스는, 리소스로서, 단일 명령을 나타내고, <command> 인스턴스의 속성 및/또는 서브리소스를 나타내는 데이터 구조체 요소를 포함한다. 이들 <command> 인스턴스 속성 및/또는 서브리소스는 명령 실행을 어떻게 트리거링하고 실행할지를 명시할 수 있다. <command> 인스턴스 속성 및/또는 서브리소스 중에는 execEnable 서브리소스("execEnable")를 나타내는 데이터 구조체 요소가 있다. "execute" 속성이라고도 할 수 있는 execEnable은 명령 실행의 상태의 변경을 호출하는 것을 용이하게 해줄 수 있다. 예를 들어, execEnable은 부울 변수일 수 있고, 이 변수의 특정의 값은 명령 실행, 명령 실행 일시정지, 명령 실행 재개 및/또는 명령 실행 취소를 호출할 수 있다. 그에 따라, execEnable의 값을 수정함으로써, 명령 실행, 명령 실행 일시정지, 명령 실행 재개 및 명령 실행 취소 중 임의의 것이 호출될 수 있다. RESTful 메소드를 사용하여 execEnable의 값이 수정될 수 있다.
예를 들어, RESTful 메소드 UPDATE는 <command> 인스턴스의 명령 실행을 호출(예컨대, 트리거링)하는 데 사용될 수 있다. RESTful 메소드 UPDATE에서의 제1 값(예컨대, "1")을 .../commands/<command>/execEnable로 명시함으로써, 명령 실행이 호출될 수 있다.
RESTful 메소드 UPDATE 및 DELETE는 <command> 인스턴스의 명령 실행을 취소(중단)하는 데 사용될 수 있다. RESTful 메소드 UPDATE에서의 제2 값(예컨대, "0")을 …/commands/<command>/execEnable로 명시함으로써, <command> 인스턴스를 중단시키기 위해 명령 실행 취소가 호출될 수 있다. 그에 부가하여 또는 다른 대안으로서, RESTful 메소드 DELETE .../commands/<command>/를 발행하여, 이러한 <command> 인스턴스가 RESTful 메소드 DELETE에 따라 삭제되기 전에 <command> 인스턴스의 명령 실행을 중단시키기 위해 명령 실행 취소가 호출될 수 있다.
execEnable에 부가하여, <command> 인스턴스 서브리소스는 execBaseDelay, exceAdditionaIDelay, execFrequency, execNumber, execResource, execStatus, execResult, execlssuer 및 execParameters 등의 서브리소스를 나타내는 데이터 구조체 요소를 포함할 수 있다.
execBaseDelay는 <command> 인스턴스의 명령 실행 이전의 최소 지연을 명시할 수 있다. exceAdditionalDelay는 랜덤한 부가 지연의 발생을 용이하게 해줄 수 있다. 총 지연은 execBaseDelay + 랜덤한 부가 지연의 합이다. execBaseDelay 및 execAdditionalDelay은 (1) Random Once 모드 및 Random Repeatedly 모드에서 명령 실행보다 특정 시간 이전에 어떻게 백오프할지를 명시하고 및/또는 (2) "Immediate and Repeatedly" 모드에서 그리고 "Random and Repeatedly" 모드에서 반복된 명령 실행에 대한 빈도수를 명시하는 것에 대한 정보를 포함할 수 있다.
execFrequency는 <command> 인스턴스의 반복된 명령 실행에 대한 빈도수를 명시할 수 있다. execNumber는 <command> 인스턴스의 명령 실행이 반복될 수 있는 횟수를 명시할 수 있다. execResource는 명령 실행을 거칠 <command> 인스턴스에 대한 리소스 URI를 명시할 수 있다. 리소스 URI는 한 그룹의 리소스를 포함하는 그룹 리소스를 가리킨다. 이러한 방식으로, 다수의 <command> 인스턴스의 명령 실행이 그룹 리소스를 가리키는 리소스 URI의 함수로서 호출될 수 있다. execResource가 선택적일 수 있다. 예를 들어, <command> 인스턴스가 <command> 인스턴스 하에서 서브리소스로서 종속되어 있는 경우, execResource가 필요하지 않을 수 있다.
execStatus는 <command> 인스턴스의 명령 실행의 현재 상태를 명시할 수 있다. 상태는, 예를 들어, 보류 중(pending), 실행 중(running), 일시정지됨(paused), 중단됨(stopped), 재개됨(resumed), 완료됨 및 성공(finished and successful), 완료됨 및 실패(finished and failure) 등일 수 있다. execResult는 <command> 인스턴스의 명령 실행의 실행 결과를 저장할 수 있다. 다수의 결과가 발생된 경우, 예를 들어, execResource가 한 그룹의 리소스를 가리키는 경우, execResult는 <command> 인스턴스의 서브리소스로서 모델링될 수 있다.
execIssuer는 <command> 인스턴스의 명령 실행을 호출하라는 요청을 발행하는 발행자의 ID를 명시할 수 있다. execParameters는 <command> 인스턴스에 고유한 파라미터를 저장하는 컨테이너(예컨대, 자리 표시자)일 수 있다.
이제 도 22c를 참조하면, 블록도는 다른 예시적인 commands 리소스 구조체를 나타낸 것이다. 이 commands 리소스 구조체 도 22c에 도시된 것과 같은 다수의 데이터 구조체 요소를 포함할 수 있다. 이 commands 리소스 구조체의 데이터 구조체 요소들 중 다수는 도 22b의 commands 리소스 구조체와 유사하다. 도 22c에 도시된 데이터 구조체 요소 중에는 다수의 속성, 즉 commandID 속성, execDisable 속성, execPause 속성, execResume 속성 및 execResult 속성을 정의하는 데이터 구조체 요소가 있다.
"execute" 속성이라고도 할 수 있는 execEnable 속성은 <command> 인스턴스의 명령 실행의 호출을 용이하게 해줄 수 있다. execEnable 속성에 대한 RESTful 메소드 UPDATE는 <command> 인스턴스의 명령 실행을 호출할 수 있다. RESTful 메소드 UPDATE의 페이로드는 비어 있거나 어떤 값으로 설정될 수 있다(예컨대, execEnable = 1).
"cancel" 속성이라고도 할 수 있는 execDisable 속성은 <command> 인스턴스의 명령 실행 취소의 호출을 용이하게 해줄 수 있다. execDisable 속성에 대한 RESTful 메소드 UPDATE는 <command> 인스턴스의 명령 실행 취소를 호출할 수 있다. RESTful 메소드 UPDATE의 페이로드는 비어 있거나 어떤 값으로 설정될 수 있다(예컨대, execEnable = 1).
execPause 속성은 <command> 인스턴스의 명령 실행 취소의 호출을 용이하게 해줄 수 있다. execPause 속성에 대한 RESTful 메소드 UPDATE는 <command> 인스턴스의 명령 실행 일시정지를 호출할 수 있다. RESTful 메소드 UPDATE의 페이로드는 비어 있거나 어떤 값으로 설정될 수 있다(예컨대, execPause = 1).
execResume 속성은 <command> 인스턴스의 명령 실행 재개의 호출을 용이하게 해줄 수 있다. execResume 속성에 대한 RESTful 메소드 UPDATE는 이러한 명령 실행 재개를 호출할 수 있다. RESTful 메소드 UPDATE의 페이로드는 비어 있거나 어떤 값으로 설정될 수 있다(예컨대, execResume = 1).
이상에서는 도 23a, 도 23b 및 도 23c의 데이터 구조체가 RESTful 메소드를 사용하여 비RESTful 관리 명령의 명령 실행을 용이하게 해준다는 것을 설명하고 있다. 이것은 BBF-TR069 및 OMA-DM의 비RESTful 관리 명령의 명령 실행을 용이하게 해주는 것을 포함한다. 예를 들어, BBF-TR069의 Reboot는 데이터 구조체에서 .../commands/reboot/로서 표현될 수 있다. BBF-TR069의 Download는 데이터 구조체에서 .../commands/download/로서 표현될 수 있다. OMA-DM의 Exec는 데이터 구조체에서 .../commands/exec/로서 표현될 수 있다. OMA-DM의 Copy는 데이터 구조체에서 .../commands/copy/로서 표현될 수 있다.
<command> 인스턴스는 다른 관리 API 또는 RPC(Remote Procedure Call)를 모델링하고 표현하는 데도 사용될 수 있다. 리소스 commands은 기존의 "리소스"의 아래에 서브리소스로서 위치될 수 있고, 따라서 각각의 commands/<command>는 트리거링될 때, 필요한 경우, "리소스"에 대해 자동으로 실행될 수 있다. 그에 부가하여, "execResource"는 commands/<command>가 실행될 수 있는 리소스를 지정하는 데 사용될 수 있다. 이 방식에서, 리소스 commands은 중앙 집중형 위치에 위치될 수 있고 "execResource"가 가리키는 리소스 바로 아래에 있을 필요는 없다. OMA-DM FUMO를 예로 하여, 2가지 방식이 이하에 예시되어 있다:
방식 1: FUMO 에서 동작을 가리키기 위해 " execResource "를 사용
도 23에 도시된 바와 같이, OMA FUMO는 다음과 같은 3가지 동작을 가진다: Download, Update, 및 DownloadAndUpdate. OMA-DM에서, 그 3가지 동작은 DM 클라이언트에 대해 비RESTful 명령 Exec 명령을 발행하기 위해 DM 서버에 의해 트리거링된다. 그 3가지 동작을 RESTful 방식으로 호출하기 위해, Exec는 도 23에 열거된 바와 같은 어떤 속성을 가지는 <command> exec로서 모델링된다. 2가지 중요한 속성은 execEnable 및 execResource이다.
네트워크 영역("NA")의 M2M 응용 프로그램은, "Download" 동작을 수행할 필요가 있을 때, 단순히 .../mgmtObjs/commands/exec/에 대해 UPDATE 메소드를 발행하여
execEnable = 1, 및
execResource = .../mgmtObjs/FUMO/Download로 설정한다.
NA는, "Update" 동작을 수행할 필요가 있을 때, 단순히 .../mgmtObjs/commands/exec/에 대해 UPDATE 메소드를 발행하여
execEnable = 1, 및
execResource = .../mgmtObjs/FUMO/Update로 설정한다.
NA는, "DownloadAndUpdate" 동작을 수행할 필요가 있을 때, 단순히 .../mgmtObjs/commands/exec/에 대해 UPDATE 메소드를 발행하여
execEnable = 1, 및
execResource = .../mgmtObjs/FUMO/DownloadAndUpdate로 설정한다.
방식 2: FUMO 에서 동작을 리모델링하기 위해 명령을 사용
도 24a 및 도 24b에 도시된 바와 같이, 다른 방식은 모든 FUMO 동작을 <command> 리소스로서 직접 리모델링하는 것이다. 동작을 실행하도록 트리거링하기 위해, 대응하는 <command>의 execEnable에 대한 UPDATE만 하면 된다. 그 결과, 부가의 Exec 명령을 정의할 필요가 전혀 없다. 이 방식에서, "execResource"이 필요하지 않다.
도 24a에 예시된 바와 같이, 3가지 FUMO 동작이, 각각, 리소스 commands 아래의 3개의 <command> 리소스(즉, download, update, downloadAndUpdate)로서 리모델링될 수 있다. 각각의 FUMO 동작이 어떤 자식/리프 노드를 가지기 때문에, 이들은 "execParameters" 하의 속성으로서 모델링될 필요가 있다. 예로서 downloadAndUpdate를 사용하여, "PkgURL"이 .../commands/downloadAndUpdate/execParameters의 속성으로서 추가될 수 있다.
NA는, "downloadAndUpdate" 동작을 수행할 필요가 있을 때, 단순히 .../mgmtObjs/FUMO/commands/downloadAndUpdate/에 대해 UPDATE 메소드를 발행하여
execEnable = 1, 및
PkgURL = 대응하는 패키지의 URL로 설정한다.
이전의 FUMO 동작이 그대로 유지될 필요가 있는 경우, 도 24b에 나타낸 바와 같이, 리모델링된 commands가 노드 Ext 아래의 서브트리로서 위치될 수 있다.
하나 이상의 실시예에서, commands 리소스 구조체는 동일한 비RESTful 관리 명령의 다수의 발행을 지원할 수 있다(예컨대, 다수의 NA 또는 다른 발행자가 동일한 비RESTful 관리 명령의 명령 실행을 요청할 수 있다).
동일한 비RESTful 관리 명령의 다수의 발행을 지원하는 commands 리소스 구조체의 2가지 예가 도 25a 및 도 25b에 도시되어 있다. 도 25a에 도시된 commands 리소스 구조체는 도 22a의 commands 리소스 구조체와 유사하고, <command>를 다수의 인스턴스의 모음, 즉 <commandInstances>로서 정의함으로써 도 22a의 commands 리소스 구조체를 확장시킨다. 앞서 기술한 바와 같은 절차는 <command>의 명령 실행을 호출하고 대응하는 <commandInstance>를 발생하는 데 사용될 수 있다. <commandInstance>는 다수의 NA에 의해 발행되는 대응하는 <command> 인스턴스를 유지할 수 있다. 발생된 <commandInstance>의 각각의 명령 실행이, 앞서 기술한 바와 같이, 그의 속성 및/또는 서브리소스에 액세스함으로써 중단되거나 수정될 수 있다. 예를 들어, <commandInstance>/execEnable을 1로부터 0으로 수정하기 위해 기존의 <commandInstance>의 명령 실행이 RESTful 메소드 UPDATE를 사용하여 중단될 수 있다. <commandInstance> 및/또는 <commandInstance>의 명령 실행의 상태의 변경이 다른 RESTful 메소드를 사용해서도 액세스 및 조작될 수 있다.
도 25b에 도시된 commands 리소스 구조체는 도 22b의 commands 리소스 구조체와 유사하고, <command>/execRequests(<execInstances>라고도 할 수 있음)를 다수의 요청 인스턴스의 모음, 즉 <requestInstances>(<execInstances>라고도 할 수 있음)으로서 정의함으로써 도 22b의 commands 리소스 구조체를 확장시킨다. 앞서 기술된 절차는 명령 실행 또는 <command>의 명령 실행의 상태의 변경을 호출하기 위해 및/또는 대응하는 <requestInstance>를 발생하기 위해 사용될 것이다. <requestInstance>는 대응하는 <command> 인스턴스(예컨대, NA에 의해 발행된 것)를 유지할 수 있다. 발생된 <requestInstance>의 각각의 명령 실행이, 앞서 기술한 바와 같이, 그의 속성에 액세스함으로써 중단되거나 수정될 수 있다. 예를 들어, 기존의 <requestInstance>의 명령 실행이 <requestInstance>/execEnable에 대해 RESTful 메소드 UPDATE를 사용하여 중단될 수 있다.
<requestInstance> 및/또는 <requestInstance>의 명령 실행의 상태의 변경이 다른 RESTful 메소드를 사용해서도 액세스 및 조작될 수 있다.
도 26a는 리소스 commands의 예시적인 구조체를 나타낸 블록도이다. 리소스 commands는 <command>의 서브리소스 및 다음과 같은 속성을 가질 수 있다:
accessRightID;
creationTime;
lastModifiedTime;
expirationTime;
searchStrings;
FFS에서 형식 설정될 수 있는 contentType;
moID;
originalMO; 및
description(즉, commands 리소스의 텍스트 형식 설명).
<command>는 또한 속성으로서 모델링될 수 있다.
도 26b는 리소스 commands의 예시적인 구조체를 나타낸 블록도이다. 리소스 commands는 서브리소스 subscriptions 및 <command>의 서브리소스를 다음과 같은 속성과 함께 가질 수 있다:
accessRightID;
creationTime;
lastModifiedTime;
expirationTime;
searchStrings;
FFS에서 형식 설정될 수 있는 contentType;
moID;
originalMO; 및
description(즉, commands 리소스의 텍스트 형식 설명).
<command>는 또한 속성으로서 모델링될 수 있다.
각각의 <command>는 서브리소스 (i) subscriptions, 및 (ii) execRequests를 포함할 수 있다. execRequests는 동일한 비RESTful 관리 명령의 명령 실행을 호출하기 위한 상이한 발행자로부터의 요청을 저장하는 자리 표시자일 수 있다. 하나 이상의 실시예에서, 이들 요청은 <command> 인스턴스에 대한 상이한 인수를 가질 수 있다.
각각의 <command> 인스턴스는 다음과 같은 속성을 가질 수 있다:
accessRightID;
creationTime;
lastModifiedTime;
expirationTime;
searchStrings;
FFS에서 형식 설정될 수 있는 contentType;
moID;
originalMO; 및
description(즉, commands 리소스의 텍스트 형식 설명).
<command>는 또한 속성으로서 모델링될 수 있다.
각각의 <command>는, 도 27a에 도시된 바와 같이, 예를 들어, 다수의 <commandInstance>를 서브리소스로서 가진다. 각각의 <command>는 다음과 같은 속성을 가진다:
accessRightID: .
creationTime: .
lastModifiedTime: .
execEnable: 명령을 실행하라고 트리거링하기 위해 사용되는 부울 변수.
execEnable이 1로부터 0으로 변경되는 경우, <commandInstance>가 중단될 수 있다. execEnable은 일시정지 등과 같은 추가의 옵션을 지원하도록 조정될 수 있다.
execMode: 명령이 어떻게 실행될 수 있는지를 명시하는 데 사용됨.
Immediate Once: 수신기가 명령을 즉각 1회만 실행함.
Immediate and Repeatedly: 수신기가 명령을 즉각 그렇지만 반복하여 실행함. 2개의 실행 사이의 간격은 컨테이너 execParameters에 의해 명시된다.
Random Once: 수신기가 명령을 랜덤한 지연 후에 1회만 실행함. 랜덤한 지연은 execParameters에 명시되어 있다.
Random and Repeatedly: 수신기가 명령을 랜덤한 지연 후에 반복하여 실행함. 랜덤한 지연 및 2개의 실행 사이의 간격은 컨테이너 execParameters에 의해 명시된다.
execBaseDelay: <commandInstance>가 실행될 수 있기 전의 최대 지연을 명시함.
exceAdditionalDelay: 랜덤한 부가 지연을 발생하는 데 사용됨. 총 지연은 execBaseDelay + 랜덤한 부가 지연의 합일 수 있다.
execFrequency: <commandInstance>가 반복하여 실행될 수 있는 빈도수를 명시함.
execNumber: <commandInstance>가 반복하여 실행될 수 있는 횟수를 명시함
execResource: <commandInstance>가 실행될 수 있는 리소스 URI를 나타낼 수 있음. 리소스 URI는 한 그룹의 리소스를 포함하는 그룹 리소스를 가리킬 수 있고; 그러면 명령이 그 리소스들 각각에 대해 실행될 수 있다. execResource는 선택적이다. <commandInstance>가 <commandInstance>가 실행될 수 있는 리소스 아래에 서브리소스로서 위치되어 있는 경우, execResource가 필요하지 않을 수 있다.
execStatus: <commandInstance>의 현재 상태를 나타낼 수 있음. 이 상태는 보류 중, 실행 중 및 완료됨(성공 또는 실패) 중 임의의 것일 수 있다.
execIssuer: <command>를 발행하는 발행자를 나타낼 수 있음.
execParameters: 각각의 단일 명령에 고유한 파라미터를 저장하는 자리 표시자임.
execBaseDelay 및 execAdditionalDelay는 "Random Once" 및 "Random Repeatedly" 모드에서 <commandInstance>를 실행하기 특정의 시간 전에 어떻게 백오프해야 하는지를 명시하는 데 사용된다. execFrequency 및 execNumber는 "Immediate and Repeatedly" 및 "Random and Repeatedly" 하에서 동일한 <commandInstance>를 실행하는 빈도수를 명시하는 데 사용된다.
"exec"로 시작하는 상기 속성들도 역시 서브리소스로서 모델링될 수 있다. "exec"로 시작하는 상기 속성들은 리소스를 조작하는 더 많은 유연성을 부가하기 위해 정상적인 RESTful CRUD 동작(즉, Create, Retrieve, Delete, Update)에 적용될 수 있다.
각각의 <commandInstance>는, 도 27b에 도시된 바와 같이, 다음과 같은 속성들을 가질 수 있다:
accessRightID: .
creationTime: .
lastModifiedTime: .
execEnable: 명령을 실행하라고 트리거링하기 위해 사용되는 부울 변수. execEnable이 1로부터 0으로 변경되는 경우, <commandInstance>가 중단될 수 있다. execEnable은 일시정지 등과 같은 추가의 옵션을 지원하도록 구성되어 있을 수 있다.
execMode: 명령이 어떻게 실행될 수 있는지를 명시하는 데 사용됨.
Immediate Once: 수신기가 명령을 즉각 1회만 실행할 수 있음.
Immediate and Repeatedly: 수신기가 명령을 즉각 그렇지만 반복하여 실행할 수 있음. 2개의 실행 사이의 간격은 컨테이너 execParameters에 의해 명시된다.
Random Once: 수신기가 명령을 랜덤한 지연 후에 1회만 실행할 수 있음. 랜덤한 지연은 execParameters에 명시되어 있을 수 있다.
Random and Repeatedly: 수신기가 명령을 랜덤한 지연 후에 반복하여 실행할 수 있음. 랜덤한 지연 및 2개의 실행 사이의 간격은 컨테이너 execParameters에 의해 명시될 수 있다.
execBaseDelay: <commandInstance>가 실행될 수 있기 전의 최대 지연을 명시하는 데 사용됨.
exceAdditionalDelay: 랜덤한 부가 지연을 발생하는 데 사용됨. 총 지연은 execBaseDelay + 랜덤한 부가 지연의 합일 수 있다.
execFrequency: <commandInstance>가 반복하여 실행될 수 있는 빈도수를 명시하는 데 사용됨.
execNumber: <commandInstance>가 반복하여 실행될 수 있는 횟수를 명시하는 데 사용됨.
execResource: <commandInstance>가 실행될 수 있는 리소스 URI를 나타낼 수 있음. 리소스 URI는 한 그룹의 리소스를 포함하는 그룹 리소스를 가리킬 수 있다. 그러면 명령이 그 리소스들 각각에 대해 실행될 수 있다. execResource는 선택적이다. <commandInstance>가 <commandInstance>가 실행될 수 있는 리소스 아래에 서브리소스로서 위치되어 있는 경우, execResource가 필요하지 않을 수 있다.
execStatus: <commandInstance>의 현재 상태를 나타낼 수 있음. 이 상태는 보류 중, 실행 중 및 완료됨(성공 또는 실패) 중 임의의 것일 수 있다.
execIssuer: <command>를 발행하는 발행자를 나타낼 수 있음.
execParameters: 각각의 단일 명령에 고유한 파라미터를 저장하는 자리 표시자임.
"exec"로 시작하는 상기 속성들도 역시 서브리소스로서 모델링될 수 있다.
이제 도 28a를 참조하면, 블록도는 다른 예시적인 commands 리소스 구조체를 나타낸 것이다. 이 commands 리소스 구조체는 다수의 데이터 구조체 요소를 포함할 수 있다. 이 commands 리소스 구조체의 데이터 구조체 요소들 중 다수는 도 22c의 commands 리소스 구조체와 유사하다. 앞서 살펴본 바와 같이, commands 리소스 구조체는 (예를 들어, 속성 commandID에 의해 식별되는) 동일한 비RESTful 관리 명령의 명령 실행에 대한 다수의 발행자의(예컨대, 다수의 NA의) 요청을 지원한다. 이러한 지원을 용이하게 해주기 위해, 일 실시예에서, 상이한 <command>가 각각의 요청에 대해 생성될 수 있다. 각각의 <command>는 상이한 이름을 가질 수 있지만, 그의 속성 commandID는 서로 동일할 수 있다. 속성 commandID(명령의 유형에 의해 분류될 수 있음)는 어느 명령(들)이 명령의 상태의 변경을 호출하는지를 명시한다. <command>의 서브리소스 execRequests가 사용되지 않을지도 모른다. 게다가, 각각의 발행자는 리소스 commands 아래에 특정의 <command>를 생성할 수 있다. 생성된 <command>의 명령 실행을 호출하기 위해 RESTful 메소드 UPDATE가 사용될 수 있다(예컨대, 리소스 <command>의 execEnable 속성에 대해 RESTful 메소드 UPDATE를 사용함).
다른 대안으로서, 동일한 <command>의 명령 실행에 대한 다수의 요청을 저장하기 위해 서브리소스 execRequests가 사용될 수 있다. 발행자는 <command>의 명령 실행을 호출하기 위해 <command>의 execEnable 속성에 대해 RESTful 메소드 UPDATE를 사용할 수 있다. 그에 따라, 수신기는 이 발행자에 대해 .../commands/<command>/execRequests/ 아래에 <requestInstance>를 생성할 수 있다. 발행자는 <requestInstance>의 속성 execDisable, execPause 및 execResume에 대해 RESTful 메소드 UPDATE를 사용하여 이 발생된 <requestInstance>를, 각각, 취소, 일시정지 및 재개할 수 있다.
그에 부가하여, 발행자는 commands 리소스 .../commands/<com- mand>/execRequests/<requestInstance>에 대해 RESTful 메소드 DELETE 동작을 사용하여 이 발생된 <requestInstance>를 삭제할 수 있다. <command>의 속성 execDisable, execPause, execResume이 사용되지 않을지도 모른다.
이상에서 상세히 기술한 바와 같이, 4개의 속성(execEnable, execDisable, execPause, execResume)은, 각각, 명령(<command> 또는 <requestInstance>)의 명령 실행, 명령 실행 일시정지, 명령 실행 재개 및 명령 실행 취소를 호출하도록 구성되고 사용된다.
대안으로서, 4개의 특별한 <command> 리소스, 즉 .../commands/enable, .../commands/disable, .../commands/pause, 및 .../commands/resume이 데이터 구조체에 생성될 수 있다. 4개의 특별한 commands는 단지 각자의 "execResource" 속성을 가질 수 있다.
.../commands/enable은 일반적인 명령 실행을 호출하기 위해 사용될 수 있다. 예를 들어, 그의 속성 execResource이 execResource = " .../commands/<command>"로 설정된 상태에서 " .../commands/enable" 리소스에 대해 RESTful 메소드 CREATE 또는 UPDATE를 발행하는 것은 " .../commands/<command>"의 명령 실행을 호출한다.
.../commands/disable은 .../commands/<command>(또는 .../commands-/<command>/execRequests/<requestInstance>)의 일반적인 명령 실행 취소를 호출하기 위해 사용될 수 있다. 예를 들어, 그의 속성 execResource가 execResource = .../commands/<command>(또는 .../commands/<command>/execRequests/<requestInstance>)로 설정된 상태에서 .../commands/disable 리소스에 대해 RESTful 메소드 CREATE 또는 UPDATE를 발행하는 것은 .../commands/<command>(또는 .../commands/<command>/exec-Requests/<requestInstance>)의 명령 실행 취소를 호출한다.
.../commands/pause는 기존의 .../commands/<command>(또는 .../commands/<command>/execRequests/<requestInstance>)의 명령 실행 일시정지를 호출하기 위해 사용될 수 있다. 예를 들어, 그의 속성 execResource가 execResource = .../commands/<command>(또는 .../commands/<command>/execRequests/<request-Instance>)로서 설정된 상태에서 .../commands/pause 리소스에 대해 RESTful 메소드 CREATE 또는 UPDATE를 발행하는 것은 .../commands/<command>(또는 .../ commands/ <command>/ execRequests/ <request-Instance>)의 명령 실행 일시정지를 호출할 수 있다.
.../commands/resume은 기존의 .../commands/<command>(또는 .../commands/<command>/execRequests/<requestInstance>)의 명령 실행 재개를 호출하기 위해 사용될 수 있다. 예를 들어, 그의 속성 execResource가 execResource = .../commands/<command>(또는 .../commands/<command>/execRequests/<requestInstance>)로 설정된 상태에서 .../commands/resume 리소스에 대해 RESTful 메소드 CREATE 또는 UPDATE를 발행하는 것은 명령 실행 재개를 호출할 수 있다.
xREM 명령 관리를 위한 예시적인 메시지 흐름도
도 29a 내지 도 29r은 리소스 commands의 xREM을 위한 예시적인 메시지 흐름을 나타낸 메시지 흐름도이다. 도 29a 내지 도 29r의 메시지 흐름은 도 22c, 도 25b 및 도 28a 내지 도 28d의 commands 리소스 구조체를 참조하여 기술된다. 메시지 흐름이 또한 리소스 commands 또는 <commands>의 다른 구조체를 사용하여 수행될 수도 있다.
이제 도 29a를 참조하면, 리소스 command 구조체를 생성하는 예시적인 메시지 흐름을 나타낸 메시지 흐름도가 도시되어 있다. 도 29a의 메시지 흐름을 상요하여 생성된 리소스 command 구조체는 도 22c, 도 25b 및 도 28a에 도시된 리소스 command 구조체 중 일부 또는 전부를 포함할 수 있다. 예를 들어, 리소스 command 구조체는 이러한 도면들에 도시된 <command>의 요소들 모두를 포함할 수 있다. 다른 대안으로서, 리소스 command 구조체는 도시된 <command>의 요소들의 서브세트를 포함할 수 있다. 이러한 서브세트는 <command>의 속성 및/또는 서브리소스의 서브세트를 포함할 수 있다. 예로서, 리소스 command 구조체는 (i) 예를 들어, "attribute", execEnable 및 commandID 등의 속성; 및 (ii) 예를 들어, execParameters, execRequests 및 subscriptions 등의 서브리소스를 포함할 수 있다. 다른 예로서, 리소스 command 구조체는 (i) 예를 들어, "attribute", execEnable, execDisable, execPause, execResume 및 commandID 등의 속성; 및 (ii) 예를 들어, execParameters, execRequests 및 subscriptions 등의 서브리소스를 포함할 수 있다. 또 다른 예로서, 리소스 command 구조체는 (i) 예를 들어, "attribute", execEnable, execDisable 및 commandID 등의 속성; 및 (ii) 예를 들어, execParameters, execRequests 및 subscriptions 등의 서브리소스를 포함할 수 있다. 리소스 command 구조체는 도 22c, 도 25b 및 도 28a에 도시된 <command>의 요소(예컨대, 속성 및 서브리소스)의 다른 조합을 포함할 수 있다.
리소스 command 구조체는 또한 도 22c, 도 25b 및 도 29a에 도시되지 않은 <command>의 다른 요소들도 포함할 수 있다. 이들 다른 요소는 도 22c, 도 25b 및 도 28a에 도시된 <command>의 요소의 임의의 조합과 함께 리소스 command 구조체에 포함될 수 있다.
리소스 command 구조체의 생성을 개시하기 위해, 발행자는 M2M 서버에 대해 RESTful 메소드 CREATE를 발행할 수 있다. 발행자는, 예를 들어, NA, M2M 디바이스 및 M2M GW 중 임의의 것일 수 있다. M2M 디바이스 또는 M2M GW는, 발행자로서, M2M 서버에의 등록에 응답하여 또는 그 등록의 일부로서 RESTful 메소드 UPDATE를 발행할 수 있다. M2M 디바이스, M2M GW 또는 NA는 다른 때에도 RESTful 메소드 CREATE를 발행할 수 있다.
<sclbase>의 주어진 노드에서 리소스 command 구조체를 생성하는 것을 용이하게 해주기 위해, RESTful 메소드 CREATE는 그 아래에 리소스 command 구조체가 생성될 수 있는 노드(또는 리소스)의 식별자를 포함할 수 있다. 예를 들어, RESTful 메소드 CREATE는, 그것을 그 아래에 리소스 command 구조체가 생성될 수 있는 노드로서 식별하기 위해, 리소스 <mgmtObjs>의 식별자(이후부터 "<mgmtObjs> 식별자"라고 함)를 포함할 수 있다.
대안으로서, RESTful 메소드 CREATE는, 리소스 <commands>를 그 아래에 리소스 command 구조체가 생성될 수 있는 노드로서 식별하기 위해, 리소스 <commands>의 식별자(이후부터 "<commands> 식별자"라고 함)를 포함할 수 있다. 각각의 <mgmtObjs> 및 <commands> 식별자는, 앞서 살펴본 바와 같이, 예를 들어, URI 링크 및 주소 중 임의의 것일 수 있다. 설명의 간소함을 위해, 이하에서는 리소스 command 구조체가 리소스 <mgmtObjs> 아래에 생성될 수 있는 것으로 가정한다. 그렇지만, 리소스 command 구조체는 <sclbase>의 노드들 중 임의의 것 아래에 생성될 수 있다.
RESTful 메소드 CREATE는 또한 리소스 command 구조체의 속성들 중 임의의 것을 채우기 위한 정보를 포함할 수 있다. 예를 들어, RESTful 메소드 CREATE는 실행되도록 요청되고 리소스 command 구조체를 사용하여 실행될 수 있는 비RESTful 명령의 유형을 나타내기 위해 commandID 속성을 채우기 위한 정보를 포함할 수 있다.
RESTful 메소드 CREATE는 리소스 command 구조체의 서브리소스들(예컨대, parameter 리소스들) 중 하나 이상을 채우기 위한 정보를 추가로 포함할 수 있다. 예를 들어, RESTful 메소드 CREATE는 execParameters 서브리소스를 채우기 위한 하나 이상의 파라미터 및/또는 인수를 포함할 수 있다. 이들 파라미터 및/또는 인수는 리소스 <command> 및/또는 비RESTful 명령에 특유한 것일 수 있다. RESTful 메소드 CREATE는 또한, 비RESTful 명령에 따라, 서브리소스 execMode, execBaseDelay, execAdditionDelay, execFrequency, execNumber 및 execResource 중 임의의 것을 채우기 위한 정보를 포함할 수 있다.
RESTful 메소드 CREATE의 수신 후에, M2M 서버는 M2M 서버의 리소스 <mgmtObjs> 아래에 리소스 command 구조체를 생성할 수 있다. 생성된 리소스 command 구조체(이후부터, "서버 <command>"라고 함)는 도 22c, 도 25b 및 도 28a에 도시된 <command>의 요소들 모두를 포함할 수 있다. 다른 대안으로서, 서버 <command>는, 예를 들어, <command>의 속성들 및/또는 서브리소스들의 서브세트 등의 도시된 <command>의 요소들의 서브세트를 포함할 수 있다. 서버 <command>는, 예를 들어, "attribute", execEnable 및 commandID 속성; 그리고 execParameters, execRequests 및 subscriptions 서브리소스를 포함할 수 있다.
다른 대안으로서, 서버 <command>는, 예를 들어, "attribute", execEnable, execDisable, execPause, execResume 및 commandID 속성; 그리고 execParameters, execRequests 및 subscriptions 서브리소스를 포함할 수 있다. 또 다른 예로서, 서버 <command>는, 예를 들어, "attribute", execEnable, execDisable 및 commandID 속성; 그리고 execParameters, execRequests 및 subscriptions 서브리소스를 포함할 수 있다. 서버 <command>는 <command>의 요소(예컨대, 속성 및 서브리소스)(도 22c, 도 25b 및 도 27a에 도시되어 있고 도시되어 있지 않음)의 다른 조합도 포함할 수 있다.
서버 <command>의 속성 및/또는 서브리소스를 채우기 위한 정보가 RESTful 메소드 CREATE에 포함되는 경우, M2M 서버는 이러한 대응하는 속성 및/또는 서브리소스를 제공된 정보로 채울 수 있다. 임의의 주어진 속성 및/또는 서브리소스를 채우기 위한 정보가 제공되지 않는 경우, M2M 서버는 이러한 속성 및/또는 서브리소스를 처음에 생성된 대로 둘 수 있다(예컨대, 비어 있거나 기본값 속성 및/또는 파라미터를 가짐). 이하에서 더 상세히 기술되는 바와 같이, 속성 및/또는 서브리소스를 채우기 위한 정보를 포함하는 RESTful 메소드 UPDATE를 M2M 서버에 발행함으로써 서버 <command>의 생성 후에 속성 및 서브리소스가 채워질 수 있다.
RESTful 메소드 CREATE에 응답하여, M2M 서버는 응답 메시지("Response")를 발행자로 송신할 수 있다. M2M 서버는, 도시된 바와 같이, 서버 <command>를 생성한 후에 Response를 송신할 수 있다. 다른 대안으로서, M2M 서버는 서버 <command>의 생성 동안 Response를 송신할 수 있다. M2M 서버는 RESTful 메소드 CREATE의 수신을 확인 응답하기 위해 확인 응답("ACK/NACK") 메시지(도시 생략)를 발행자로 송신할 수 있다. 발행자에 의한 ACK/NACK 메시지의 수신이 없는 것은 M2M 서버에 의한 RESTful 메소드 CREATE의 확인 응답이 없는 것을 나타낼 수 있다.
Response는 M2M 서버가 서버 <command>를 성공적으로 생성했는지 생성하는 데 실패했는지를 나타내는 표시(예컨대, 코드)를 포함할 수 있다. 이 표시는 성공적인 생성을 나타내는 하나의 값 및 실패를 나타내는 다른 값일 수 있다. 다른 대안으로서, Response는 M2M 서버가 서버 <command>를 성공적으로 생성했다는 것을 나타내는 제1 표시(예컨대, 코드), 및 서버 <command>를 생성하는 데 실패했다는 것을 나타내는 제2 표시(예컨대, 코드)를 포함할 수 있다. 다른 대안으로서, M2M 서버는 M2M 서버가 서버 <command>를 성공적으로 생성한 경우에만 Response를 발행할 수 있다.
Response는 생성 동안 서버 <command>에 할당된 노드의 식별자("서버 <command> 식별자")를 포함할 수 있다. 이 서버 <command> 식별자는 서버 <command>에 액세스하는 데 사용될 수 있다. 서버 <command> 식별자는, 예를 들어, 노드의 URI 링크 또는 주소일 수 있다.
Response는 또한 생성 동안 execEnable 서브리소스에 할당된 노드의 식별자("execEnable 식별자")를 포함할 수 있다. 이상에서 기술되고 이하에서 더 상세히 기술되는 바와 같이, execEnable 식별자는 명령 실행의 상태의 변경을 호출(예컨대, 명령 실행, 명령 실행 취소, 명령 실행 일시정지 및 명령 실행 재개 중 임의의 것을 호출)하는 데 사용될 수 있다.
다른 대안으로서, Response는 또한 execEnable 식별자; 생성 동안 execDisable에 할당된 노드의 식별자("execDisable 식별자")(있는 경우); 생성 동안 execPause에 할당된 노드의 식별자("execPause 식별자")(있는 경우); 및 생성 동안 execResume에 할당된 노드의 식별자("execResume 식별자")(있는 경우)를 포함할 수 있다. 이상에서 기술되고 이하에서 더 상세히 기술되는 바와 같이, 각각의 execEnable, execDisable, execPause 및 execResume 식별자는 명령 실행의 상태의 변경을 호출하는 데 사용될 수 있다. execEnable은 명령 실행을 호출하는 데 사용될 수 있다. execDisable은 명령 실행 취소를 호출하는 데 사용될 수 있다. execPause는 명령 실행 일시정지를 호출하는 데 사용될 수 있다. execResume은 명령 실행 재개를 호출하는 데 사용될 수 있다.
대안으로서, M2M 서버는 execEnable, execDisable, execPause 및 execResume 식별자(있는 경우) 중 임의의 것을 서버 <command>의 속성 또는 서브리소스(예를 들어, "attribute" 속성 등)에 저장할 수 있다. 이러한 방식으로, execEnable, execDisable, execPause 및 execResume 식별자 중 임의의 것이 나중에 검색될 수 있다.
이제 도 29b를 참조하면, 서버 <command> 등의 리소스 command 구조체로부터 정보를 검색하는 예시적인 메시지 흐름을 나타내는 메시지 흐름도가 도시되어 있다. 검색을 개시하기 위해, NA(즉, 발행자)는 M2M 서버에 대해 RESTful 메소드 RETRIEVE를 발행할 수 있다. RESTful 메소드 RETRIEVE는 서버 <command> 식별자를 포함할 수 있다.
RESTful 메소드 RETRIEVE의 수신 후에, M2M 서버는 서버 <command>를 찾아내기 위해 서버 <command> 식별자를 사용할 수 있다. 일단 찾아내면, M2M 서버는 검색가능 정보(예컨대, 속성, 파라미터 및/또는 인수)(이후부터 "검색된 속성 정보" 및/또는 "검색된 서브리소스 정보"라고 함)를 가지는 서버 <command>의 속성 및/또는 서브리소스로부터 이러한 검색가능 정보를 질의하고 획득할 수 있다. 검색된 속성 및/또는 검색된 서브리소스 정보는 저장된 execEnable, execDisable, execPause 및 execResume 식별자 중 임의의 것을 포함할 수 있다.
검색된 속성 및/또는 검색된 서브리소스 정보를 획득한 후에, M2M 서버는 Response를 NA로 송신할 수 있다. 이 Response는 서버 <command> 식별자 및 검색된 속성 및/또는 검색된 서브리소스 정보를 포함할 수 있다.
대안으로서, RESTful 메소드 RETRIEVE는 이러한 검색가능 정보를 가지는 서버 <command>의 속성 및/또는 서브리소스로부터 검색가능 정보의 하나 이상의 선택 부분을 검색하는 데 사용될 수 있다. 이것을 용이하게 해주기 위해, RESTful 메소드 RETRIEVE는 검색가능 정보의 선택 부분을 가지는 서버 <command>의 속성 및/또는 서브리소스에 할당된 각각의 노드의 식별자를 포함할 수 있다. 식별자(또는 2개 이상인 경우, 식별자들)를 사용하여, M2M 서버는 검색가능 정보의 선택 부분(이후부터 "선택되는 검색된 속성 및/또는 검색된 서브리소스 정보"라고 함)을 찾아내고, 질의하며 획득할 수 있다. M2M 서버는 이어서 선택되는 검색된 속성 및/또는 검색된 서브리소스 정보를 포함하는 Response를 NA로 송신할 수 있다.
비록 도시되어 있지는 않지만, M2M 서버는 또한 RESTful 메소드 RETRIEVE의 수신을 확인 응답하기 위해 ACK/NACK 메시지를 발행자로 송신할 수 있다. (예컨대, 특정의 시간 내에) 발행자에 의한 ACK/NACK 메시지의 수신이 없는 것은 M2M 서버에 의한 RESTful 메소드 RETRIEVE의 확인 응답이 없는 것을 나타낼 수 있다.
이제 도 29c를 참조하면, 서버 <command> 또는 서버 <command> 인스턴스의 모음("서버 <command> 인스턴스") 등의 리소스 command 구조체를 삭제하는 예시적인 메시지 흐름을 나타낸 메시지 흐름도가 도시되어 있다. 삭제를 개시하기 위해, 발행자는 M2M 서버에 대해 RESTful 메소드 DELETE를 발행할 수 있다. 발행자는 NA, M2M 디바이스 또는 M2M GW일 수 있다. M2M 디바이스 및/또는 M2M GW는 재부팅, 비RESTful 명령의 취소, 등록 해제 등에 응답하여 RESTful 메소드 DELETE를 발행할 수 있다.
RESTful 메소드 DELETE는 서버 <command> 식별자를 포함할 수 있다. 다른 대안으로서, RESTful 메소드 DELETE는 그 아래에 서버 <command> 인스턴스의 모음이 생성되어 있는 리소스(예컨대, 서버 <commands>)에 할당된 노드의 식별자(이후부터, "서버 <commands> 식별자"라고 함)를 포함할 수 있다.
RESTful 메소드 DELETE의 수신 후에, M2M 서버는 서버 <command> 또는 서버 <commands>를 찾아내어 삭제하기 위해, 각각, 서버 <command> 식별자 또는 서버 <commands> 식별자를 사용할 수 있다. 이것은 서버 <command> 또는 서버 <commands>의 모든 속성 및/또는 서브리소스를 삭제하는 것, 이러한 서버 <commands>의 각각의 서버 <command> 인스턴스를 삭제하는 것을 포함할 수 있다.
RESTful 메소드 DELETE에 응답하여, M2M 서버는 Response를 발행자로 송신할 수 있다. M2M 서버는, 도시된 바와 같이, 서버 <command> 또는 서버 <commands>를 삭제한 후에 Response를 송신할 수 있다. 다른 대안으로서, M2M 서버는 서버 <command> 또는 서버 <commands>의 삭제 동안 Response를 송신할 수 있다. M2M 서버는 또한 RESTful 메소드 DELETE의 수신을 확인 응답하기 위해 ACK/NACK 메시지(도시 생략)를 발행자로 송신할 수 있다. 발행자에 의한 ACK/NACK 메시지의 수신이 없는 것은 M2M 서버에 의한 RESTful 메소드 DELETE의 확인 응답이 없는 것을 나타낼 수 있다.
Response는 M2M 서버가 서버 <command> 또는 서버 <commands>를 성공적으로 삭제했는지 삭제하는 데 실패했는지를 나타내는 표시(예컨대, 코드)를 포함할 수 있다. 이 표시는 성공적인 삭제를 나타내는 하나의 값 및 실패를 나타내는 다른 값일 수 있다. 다른 대안으로서, Response는 M2M 서버가 서버 <command> 또는 서버 <commands>를 성공적으로 삭제했다는 것을 나타내는 제1 표시(예컨대, 코드), 및 서버 <command> 또는 서버 <commands>를 삭제하는 데 실패했다는 것을 나타내는 제2 표시(예컨대, 코드)를 포함할 수 있다. 다른 대안으로서, M2M 서버는 M2M 서버가 서버 <command> 또는 서버 <commands>를 성공적으로 삭제한 경우에만 Response를 발행할 수 있다.
도 29d는 비RESTful 명령을 수행하는 데 사용하기 위한 정보로 서버 <command> 등의 리소스 command 구조체를 업데이트하는 예시적인 메시지 흐름을 나타낸 메시지 흐름도이다. 도 29e 내지 도 29n은 비RESTful 명령의 명령 실행을 호출하기 위해 서버 <command> 등의 리소스 command 구조체를 업데이트하는 예시적인 메시지 흐름을 나타낸 흐름도이다. 도 29d의 메시지 흐름 및 도 29e 및 도 29n의 메시지 흐름이 RESTful 메소드 UPDATE를 사용할 수 있지만, 도 29d의 메시지 흐름은 비RESTful 명령을 수행하는 데(즉, 명령 실행이 호출된 후에) 사용될 수 있는 정보(예컨대, 속성, 파라미터 및/또는 인수 중 임의의 것)로 서버 <command> 등의 리소스 command 구조체의 요소를 채우기 위해 RESTful 메소드 UPDATE를 사용할 수 있다. 그렇지만, 도 20e 내지 도 29N의 메시지 흐름은 비RESTful 명령의 명령 실행을 호출하기 위해 RESTful 메소드 UPDATE를 사용할 수 있다.
이제 도 29d를 참조하면, NA(즉, 발행자)는 업데이트를 개시하기 위해 M2M 서버에 대해 RESTful 메소드 UPDATE를 발행할 수 있다. RESTful 메소드 UPDATE는 서버 <command> 식별자와 서버 <command>의 속성 및/또는 서브리소스를 채우기 위한 정보(예컨대, 속성, 파라미터 및/또는 인수)를 포함할 수 있다. 상기 RESTful 메소드 CREATE와 같이, RESTful 메소드 UPDATE는 실행되도록 요청되고 리소스 command 구조체를 사용하여 실행될 수 있는 비RESTful 명령의 유형을 나타내기 위해 commandID 속성을 채우기 위한 정보를 포함할 수 있다.
RESTful 메소드 UPDATE는 리소스 command 구조체의 서브리소스들(예컨대, parameter 리소스들) 중 하나 이상을 채우기 위한 정보를 추가로 포함할 수 있다. 예를 들어, RESTful 메소드 UPDATE는 execParameters 서브리소스를 채우기 위한 하나 이상의 파라미터 및/또는 인수를 포함할 수 있다. 이들 파라미터 및/또는 인수는 리소스 <command> 및/또는 비RESTful 명령에 특유한 것일 수 있다. RESTful 메소드 UPDATE는 또한, 비RESTful 명령에 따라, 서브리소스 execMode, execBaseDelay, execAdditionDelay, execFrequency, execNumber 및 execResource 중 임의의 것을 채우기 위한 정보를 포함할 수 있다.
RESTful 메소드 UPDATE의 수신 후에, M2M 서버는 서버 command 식별자를 사용하여 서버 <command>를 찾아낸다. 그 후에, M2M 서버는 이러한 서버 <command>의 속성 및/또는 서브리소스를 제공된 정보로 채울 수 있다. 임의의 주어진 속성 및/또는 서브리소스를 채우기 위한 정보가 제공되지 않는 경우, M2M 서버는 이러한 속성 및/또는 서브리소스를 처음에 생성된 또는 마지막으로 수정된 대로 둘 수 있다(예컨대, 비어 있거나 기본값 속성 및/또는 파라미터를 가짐).
RESTful 메소드 UPDATE에 응답하여, M2M 서버는 Response를 발행자로 송신할 수 있다. M2M 서버는, 도시된 바와 같이, 서버 <command>를 업데이트한 후에 Response를 송신할 수 있다. 다른 대안으로서, M2M 서버는 서버 <command>의 업데이트 동안 Response를 송신할 수 있다. M2M 서버는 또한 RESTful 메소드 UPDATE의 수신을 확인 응답하기 위해 ACK/NACK 메시지(도시 생략)를 발행자로 송신할 수 있다. (예컨대, 특정의 시간 내에) 발행자에 의한 ACK/NACK 메시지의 수신이 없는 것은 M2M 서버에 의한 RESTful 메소드 UPDATE의 확인 응답이 없는 것을 나타낼 수 있다.
Response는 M2M 서버가 서버 <command>를 성공적으로 업데이트했는지 업데이트하는 데 실패했는지를 나타내는 표시(예컨대, 코드)를 포함할 수 있다. 이 표시는 성공적인 업데이트를 나타내는 하나의 값 및 실패를 나타내는 다른 값일 수 있다. 다른 대안으로서, Response는 M2M 서버가 서버 <command>를 성공적으로 업데이트했다는 것을 나타내는 제1 표시(예컨대, 코드), 및 서버 <command>를 업데이트하는 데 실패했다는 것을 나타내는 제2 표시(예컨대, 코드)를 포함할 수 있다. 다른 대안으로서, M2M 서버는 M2M 서버가 서버 <command>를 성공적으로 업데이트한 경우에만 Response를 발행할 수 있다.
이 Response는 또한 서버 <command> 식별자 및/또는 업데이트된 속성 및/또는 서브리소스 정보를 포함할 수 있다. Response는 속성 및/또는 서브리소스를 업데이트하는 데 사용된 정보 또는 동일한 것을 나타내는 확인을 추가로 포함할 수 있다.
이제 도 29e를 참조하면, 비RESTful 명령의 명령 실행을 호출하기 위해 서버 <command> 등의 리소스 command 구조체를 업데이트하는 예시적인 메시지 흐름을 나타낸 흐름도가 도시되어 있다. 업데이트를 개시하기 위해, NA(즉, 발행자)는 M2M 서버에 대해 RESTful 메소드 UPDATE를 발행한다. 이 RESTful 메소드 UPDATE는, 서브리소스 execEnable(예컨대, .../<command>/execEnable)을 명시하는 것과 함께, 서버 <command> 식별자를 포함할 수 있다. 다른 대안으로서, RESTful 메소드 UPDATE는 execEnable 식별자를 포함할 수 있다.
이 RESTful 메소드 UPDATE에 응답하여, M2M 서버는 RESTful 메소드 UPDATE의 수신을 확인 응답하기 위해 ACK/NACK 메시지(Response로서 도시됨)를 발행자로 송신할 수 있다. 발행자에 의한 ACK/NACK 메시지의 수신이 없는 것은 M2M 서버에 의한 RESTful 메소드 UPDATE의 확인 응답이 없는 것을 나타낼 수 있다.
M2M 서버는 서버 <command>의 속성 및/또는 서브리소스에 따라 비RESTful 명령의 명령 실행을 호출할 수 있다. M2M 서버는, 명령 실행을 호출하는 것의 일부로서, 다수의 함수를 수행할 수 있다. 이들 함수는, 예를 들어, 서버 <command>에 의해(예컨대, commandID에 의해) 식별되는 명령을, M2M 디바이스 또는 M2M GW에 의해 해석되거나 실행될 수 있는 비RESTful 명령으로 변환하는 것을 포함할 수 있다. 이들 함수는 또한 서버 <command>에서 식별되는 명령과 M2M 디바이스 또는 M2M GW에 의해 해석되거나 실행될 수 있는 비RESTful 명령 사이에서 속성, 파라미터 및/또는 인수("매핑된 속성, 파라미터 및/또는 인수")를 매핑하는 함수를 포함할 수 있다.
M2M 서버는 또한 호출된 서버 <command>를 유지하고 추적하기 위해 execRequests 서브리소스 아래에 리소스 <requestInstance>를 생성할 수 있다. 리소스 <requestInstance>는 서버 <command>의 속성 및/또는 서브리소스 중 하나 이상을 포함할 수 있다. M2M 서버는 리소스 <requestInstance>를 생성할 때 이러한 속성 및/또는 서브리소스를 서버 <command>로부터 상속 또는 임포트할 수 있다. 서버 <command>가 요소들의 다양한 조합을 포함할 수 있는 경우, 리소스 <requestInstance>도 역시 요소들의 다양한 조합을 포함할 수 있다. 예를 들어, 리소스 <requestInstance>는, 예를 들어, 도 22c, 도 25b 및 도 28a에 도시된 서버 <command>에 대한 귀결일 수 있는, 도 25b, 도 28c 및 도 28d에 도시된 리소스 <requestInstance>의 요소들 모두를 포함할 수 있다.
다른 대안으로서, 리소스 <requestInstance>는 도시된 리소스 <requestInstance>의 요소들의 서브세트를 포함할 수 있다. 이러한 서브세트는 리소스 <requestInstance>의 속성 및/또는 서브리소스의 서브세트를 포함할 수 있다. 예로서, 리소스 <requestInstance>는 "attribute", execEnable, execStatus, execResult 및 execDisable 속성; 그리고 subscriptions 서브리소스를 포함할 수 있다. 다른 예로서, 리소스 <requestInstance>는 "attribute", execEnable, execStatus, execResult, execDisable, execPause, 및 execResume 속성; 그리고 subscriptions 서브리소스를 포함할 수 있다. 또 다른 예로서, 리소스 <requestInstance>는 "attribute", execEnable, execStatus 및 execResult 속성; 그리고 subscriptions 서브리소스를 포함할 수 있다. 서브리소스는 도 25b, 도 28c 및 도 28d에 도시된 서버 <command> 및/또는 리소스 <requestInstance>의 요소(예컨대, 속성 및 서브리소스)의 다른 조합을 포함할 수 있다.
리소스 <requestInstance>는 또한 도 25b, 도 28c 및 도 28d에 도시되지 않은 <command>의 다른 요소들도 포함할 수 있다. 이들 다른 요소는 도 25b, 도 28c 및 도 28d에 도시된 리소스 <requestInstance>의 요소들의 임의의 조합과 함께 리소스 <requestInstance>에 포함될 수 있다.
execRequests 서브리소스 하에 리소스 <requestInstance>를 생성할 시에, M2M 서버는 리소스 <requestInstance>가 생성되는 노드의 식별자("<requestInstance> 식별자")를 리소스 <requestInstance>에 할당할 수 있다. 이 <requestInstance> 식별자는, 앞서 살펴본 바와 같이, 예를 들어, URI, 링크 및 주소 중 임의의 것일 수 있다.
M2M 서버는 리소스 <requestInstance>에 임포트되거나 그에 의해 상속되는 서버 <command>의 속성 및/또는 서브리소스 내에 채워지는 정보의 일부 또는 전부를 리소스 <requestInstance>에 임포트할 수 있다(리소스 <requestInstance>를 상속시킬 수 있음). 이러한 정보는 서버 <command>의 execParameters 서브리소스에 채워지는 하나 이상의 파라미터 및/또는 인수를 포함할 수 있다. 이 정보는 또한, 예를 들어, execMode, execBaseDelay, execAdditionDelay, execFrequency, execNumber 및 execResource 서브리소스에 채워지는 정보의 일부 또는 전부를 포함할 수 있다.
리소스 <requestInstance>를 생성한 후에, M2M 서버는 M2M 디바이스 및/또는 M2M GW에서 명령 실행을 호출하기 위해 요청 메시지("Request")를 이러한 M2M 디바이스 및/또는 M2M GW로 송신할 수 있다. Request는 비RESTful 명령을 포함할 수 있다. Request는 또한 매핑된 속성, 파라미터 및 인수 중 임의의 것을 포함할 수 있다.
Request에 응답하여, M2M 디바이스 및/또는 M2M GW는 비RESTful 명령을 실행할 수 있다. M2M 디바이스 및/또는 M2M GW는 Request에 대한 Response("Command-execution Response")를 송신할 수 있다. 이 Command-execution Response는 결과(있는 경우)(" { }" 심볼로 표시되어 있음)를 포함할 수 있다. M2M 서버는 결과를 추출하고, 나중의 검색을 위해, 리소스 <requestInstance>의 execResult 서브리소스에 저장할 수 있다. 다른 대안으로서 및/또는 그에 부가하여, M2M 서버는 NA에 대한 Response("NA Response")에서 결과를 송신할 수 있다. 결과를 획득한 후에, NA는 이를 처리할 수 있다.
Command-execution Response는 또한 M2M 디바이스 및/또는 M2M GW가 비RESTful 명령의 명령 실행을 성공적으로 수행했는지 비RESTful 명령의 명령 실행을 수행하는 데 실패했는지를 나타내는 표시(예컨대, 코드)를 포함할 수 있다. 이 표시는 성공적인 명령 실행을 나타내는 하나의 값 및 실패를 나타내는 다른 값일 수 있다. 다른 대안으로서, Response는 M2M 디바이스 및/또는 M2M GW가 명령 실행을 성공적으로 수행했다는 것을 나타내는 제1 표시(예컨대, 코드), 그리고 M2M 디바이스 및/또는 M2M GW가 명령 실행을 수행하는 데 실패했다는 것을 나타내는 제2 표시(예컨대, 코드)를 포함할 수 있다. 다른 대안으로서, M2M 디바이스 및/또는 M2M GW가 명령 실행을 성공적으로 수행한 경우에만, M2M 디바이스 및/또는 M2M GW는 Response를 발행할 수 있다.
비록 도시되어 있지 않지만, M2M 서버는 M2M 디바이스 및/또는 M2M GW가 비RESTful 명령의 명령 실행을 수행하는 데 실패할 때에 리소스 <requestInstance>를 삭제할 수 있다. M2M 서버는 또한, M2M 디바이스 및/또는 M2M GW가 비RESTful 명령의 명령 실행을 수행하는 데 실패했다고 통보받은 것에 응답하여, 서버 <command> 및/또는 하나 이상의 서버 <commands>를 삭제할 수 있다.
이제 도 29f를 참조하면, 비RESTful 명령의 명령 실행을 호출하기 위해 서버 <command> 등의 리소스 command 구조체를 업데이트하는 다른 예시적인 메시지 흐름을 나타낸 흐름도가 도시되어 있다. 도 29f의 메시지 흐름은, 본 명세서에 기술되어 있는 것을 제외하고는, 도 29e의 메시지 흐름과 유사하다. 도 29f의 메시지 흐름에서, M2M 서버는 리소스 <requestInstance>를 생성하기 전에 Request를 발행할 수 있다. 또한, M2M 서버는 리소스 <requestInstance>를 생성한 후에 Command-execution Response을 수신할 수 있다.
도 29g는 비RESTful 명령의 명령 실행을 호출하기 위해 서버 <command> 등의 리소스 command 구조체를 업데이트하는 다른 예시적인 메시지 흐름을 나타낸 흐름도이다. 도 29g의 메시지 흐름은, 본 명세서에 기술되어 있는 것을 제외하고는, 도 29e의 메시지 흐름과 유사하다. 도 29g의 메시지 흐름에서, execDisable, execPause 및/또는 execResume 속성(또는 서브리소스)를 포함하는 리소스 <requestInstance>를 생성한 후에, M2M 서버는 대응하는 execDisable, execPause 및/또는 execResume 식별자를 발행자로 송신할 수 있다.
다른 대안으로서, M2M 서버는 execEnable, execDisable, execPause 및 execResume 식별자 중 임의의 것을 리소스 <requestInstance>의 속성 또는 서브리소스(예를 들어, "attribute" 속성 등)에 저장할 수 있다. 이러한 방식으로, execEnable, execDisable, execPause 및 execResume 식별자 중 임의의 것이 나중에 검색될 수 있다. 이하에서 기술되는 바와 같이, 발행자(예컨대, NA)는 명령 실행 취소, 명령 실행 일시정지 및/또는 명령 실행 재개를 호출하기 위해, 각각, execDisable, execPause 및/또는 execResume 식별자를 사용할 수 있다.
이제 도 29h를 참조하면, 비RESTful 명령의 명령 실행을 호출하기 위해 서버 <command> 등의 리소스 command 구조체를 업데이트하는 다른 예시적인 메시지 흐름을 나타낸 흐름도가 도시되어 있다. 도 29h의 메시지 흐름은, 본 명세서에 기술되어 있는 것을 제외하고는, 도 29g의 메시지 흐름과 유사하다. 도 29g의 메시지 흐름에서, M2M 서버는 리소스 <requestInstance>를 생성하기 전에 Request를 발행할 수 있다. 또한, M2M 서버는 리소스 <requestInstance>를 생성한 후에 Command-execution Response을 수신할 수 있다.
도 29i 내지 도 29j는 비RESTful 명령의 명령 실행의 상태의 변경을 호출하기 위해 서버 <command> 등의 리소스 command 구조체를 업데이트하는 예시적인 메시지 흐름을 나타낸 흐름도이다. 업데이트를 개시하기 위해, NA(즉, 발행자)는 M2M 서버에 대해 RESTful 메소드 UPDATE를 발행할 수 있다. 이 RESTful 메소드 UPDATE는, 서브리소스 execDisable(예컨대, .../<command>/execDisable)을 명시하는 것과 함께, <requestInstance> 식별자를 포함할 수 있다. 다른 대안으로서, RESTful 메소드 UPDATE는 M2M 서버로부터 송신된 Response를 통해(도 29i) 또는 리소스 <requestInstance>의 속성으로부터 그를 검색한 후에(도 29j) 획득된 execDisable 식별자를 포함할 수 있다.
이 RESTful 메소드 UPDATE에 응답하여, M2M 서버는 RESTful 메소드 UPDATE의 수신을 확인 응답하기 위해 ACK/NACK 메시지(Response로서 도시됨)를 발행자로 송신할 수 있다. 발행자에 의한 ACK/NACK 메시지의 수신이 없는 것은 M2M 서버에 의한 RESTful 메소드 UPDATE의 확인 응답이 없는 것을 나타낼 수 있다.
M2M 서버는 이어서 서버 <command>의 속성 및/또는 서브리소스에 따라 비RESTful 명령의 명령 실행 취소를 호출할 수 있다. M2M 서버는, 명령 실행 취소를 호출하는 것의 일부로서, 다수의 함수를 수행할 수 있다. 이들 함수는, 예를 들어, 리소스 <requestInstance>에 의해 식별된 명령 실행 취소를 실행 중인 비RESTful 명령의 명령 실행 취소("비RESTful 취소 명령")를 호출하는 비RESTful 명령으로 변환하는 것을 포함할 수 있다. 이들 함수는 또한 리소스 <requestInstance>에 의해 식별된 명령과 비RESTful 취소 명령 사이에서 매핑된 속성, 파라미터 및/또는 인수를 준비하는 함수를 포함할 수 있다.
명령 실행 취소를 호출하는 함수를 수행한 후에, M2M 서버는 M2M 디바이스 및/또는 M2M GW에서 명령 실행 취소를 호출하기 위해 Request를 이러한 M2M 디바이스 및/또는 M2M GW로 송신할 수 있다. Request는 비RESTful 취소 명령을 포함할 수 있다. Request는 또한 비RESTful 취소 명령을 수행하기 위한 매핑된 속성, 파라미터 및 인수 중 임의의 것을 포함할 수 있다.
Request에 응답하여, M2M 디바이스 및/또는 M2M GW는 비RESTful 취소 명령을 실행할 수 있다. M2M 디바이스 및/또는 M2M GW는 Command-execution Response를 송신할 수 있다. 이 Command-execution Response는 결과(있는 경우)를 포함할 수 있다. M2M 서버는 결과를 추출하고, 나중의 검색을 위해, 리소스 <requestInstance>의 execResult 서브리소스에 저장할 수 있다. 다른 대안으로서 및/또는 그에 부가하여, M2M 서버는 NA Response에서 결과를 송신할 수 있다. 결과(있는 경우)를 획득한 후에, NA는 이를 처리할 수 있다.
Command-execution Response는 또한 M2M 디바이스 및/또는 M2M GW가 비RESTful 취소 명령의 명령 실행 취소를 성공적으로 수행했는지 비RESTful 취소 명령의 명령 실행 취소를 수행하는 데 실패했는지를 나타내는 표시(예컨대, 코드)를 포함할 수 있다. 이 표시는 성공적인 명령 실행 취소를 나타내는 하나의 값 및 실패를 나타내는 다른 값일 수 있다. 다른 대안으로서, Response는 M2M 디바이스 및/또는 M2M GW가 명령 실행 취소를 성공적으로 수행했다는 것을 나타내는 제1 표시(예컨대, 코드), 그리고 M2M 디바이스 및/또는 M2M GW가 명령 실행 취소를 수행하는 데 실패했다는 것을 나타내는 제2 표시(예컨대, 코드)를 포함할 수 있다. 다른 대안으로서, M2M 디바이스 및/또는 M2M GW가 명령 실행 취소를 성공적으로 수행한 경우에만, M2M 디바이스 및/또는 M2M GW는 Response를 발행할 수 있다.
비록 도시되어 있지 않지만, M2M 서버는 M2M 디바이스 및/또는 M2M GW가 비RESTful 명령의 명령 실행 취소를 수행하는 데 실패할 때에 리소스 <requestInstance>를 삭제할 수 있다. M2M 서버는 또한, M2M 디바이스 및/또는 M2M GW가 비RESTful 취소 명령의 명령 실행 취소를 수행하는 데 실패했다고 통보받은 것에 응답하여, 서버 <command> 및/또는 하나 이상의 서버 <commands>를 삭제할 수 있다.
도 29k 및 도 29l은 비RESTful 명령의 명령 실행의 상태의 변경을 호출하기 위해 서버 <command> 등의 리소스 command 구조체를 업데이트하는 예시적인 메시지 흐름을 나타낸 흐름도이다. 업데이트를 개시하기 위해, NA(즉, 발행자)는 M2M 서버에 대해 RESTful 메소드 UPDATE를 발행할 수 있다. 이 RESTful 메소드 UPDATE는, 서브리소스 execPause(예컨대, .../<command>/execPause)를 명시하는 것과 함께, <requestInstance> 식별자를 포함할 수 있다. 다른 대안으로서, RESTful 메소드 UPDATE는 M2M 서버로부터 송신된 Response를 통해(도 29k) 또는 리소스 <requestInstance>의 속성으로부터 그를 검색한 후에(도 29l) 획득된 execPause 식별자를 포함할 수 있다.
이 RESTful 메소드 UPDATE에 응답하여, M2M 서버는 RESTful 메소드 UPDATE의 수신을 확인 응답하기 위해 ACK/NACK 메시지(Response로서 도시됨)를 발행자로 송신할 수 있다. 발행자에 의한 ACK/NACK 메시지의 수신이 없는 것은 M2M 서버에 의한 RESTful 메소드 UPDATE의 확인 응답이 없는 것을 나타낼 수 있다.
M2M 서버는 이어서 서버 <command>의 속성 및/또는 서브리소스에 따라 비RESTful 명령의 명령 실행 일시정지를 호출할 수 있다. M2M 서버는, 명령 실행 일시정지를 호출하는 것의 일부로서, 다수의 함수를 수행할 수 있다. 이들 함수는, 예를 들어, 리소스 <requestInstance>에 의해 식별된 명령 실행 일시정지를 실행 중인 비RESTful 명령의 명령 실행 일시정지("비RESTful 일시정지 명령")를 호출하는 비RESTful 명령으로 변환하는 것을 포함할 수 있다. 이들 함수는 또한 리소스 <requestInstance>에 의해 식별된 명령과 비RESTful 일시정지 명령 사이에서 매핑된 속성, 파라미터 및/또는 인수를 준비하는 함수를 포함할 수 있다.
명령 실행 일시정지를 호출하는 함수를 수행한 후에, M2M 서버는 M2M 디바이스 및/또는 M2M GW에서 명령 실행 일시정지를 호출하기 위해 Request를 이러한 M2M 디바이스 및/또는 M2M GW로 송신할 수 있다. Request는 비RESTful 일시정지 명령을 포함할 수 있다. Request는 또한 비RESTful 일시정지 명령을 수행하기 위한 매핑된 속성, 파라미터 및 인수 중 임의의 것을 포함할 수 있다.
Request에 응답하여, M2M 디바이스 및/또는 M2M GW는 비RESTful 일시정지 명령을 실행할 수 있다. M2M 디바이스 및/또는 M2M GW는 Command-execution Response를 송신할 수 있다. 이 Command-execution Response는 결과(있는 경우)를 포함할 수 있다. M2M 서버는 결과를 추출하고, 나중의 검색을 위해, 리소스 <requestInstance>의 execResult 서브리소스에 저장할 수 있다. 다른 대안으로서 및/또는 그에 부가하여, M2M 서버는 NA Response에서 결과를 송신할 수 있다. 결과(있는 경우)를 획득한 후에, NA는 이를 처리할 수 있다.
Command-execution Response는 또한 M2M 디바이스 및/또는 M2M GW가 비RESTful 일시정지 명령의 명령 실행 일시정지를 성공적으로 수행했는지 비RESTful 일시정지 명령의 명령 실행 일시정지를 수행하는 데 실패했는지를 나타내는 표시(예컨대, 코드)를 포함할 수 있다. 이 표시는 성공적인 명령 실행 일시정지를 나타내는 하나의 값 및 실패를 나타내는 다른 값일 수 있다. 다른 대안으로서, Response는 M2M 디바이스 및/또는 M2M GW가 명령 실행 일시정지를 성공적으로 수행했다는 것을 나타내는 제1 표시(예컨대, 코드), 그리고 M2M 디바이스 및/또는 M2M GW가 명령 실행 일시정지를 수행하는 데 실패했다는 것을 나타내는 제2 표시(예컨대, 코드)를 포함할 수 있다. 다른 대안으로서, M2M 디바이스 및/또는 M2M GW가 명령 실행 일시정지를 성공적으로 수행한 경우에만, M2M 디바이스 및/또는 M2M GW는 Command-execution Response를 발행할 수 있다.
비록 도시되어 있지 않지만, M2M 서버는 M2M 디바이스 및/또는 M2M GW가 비RESTful 명령의 명령 실행 일시정지를 수행하는 데 실패할 때에 리소스 <requestInstance>를 삭제할 수 있다. M2M 서버는 또한, M2M 디바이스 및/또는 M2M GW가 비RESTful 일시정지 명령의 명령 실행 일시정지를 수행하는 데 실패했다고 통보받은 것에 응답하여, 서버 <command> 및/또는 하나 이상의 서버 <commands>를 삭제할 수 있다.
도 29m 및 도 29n은 비RESTful 명령의 명령 실행의 상태의 변경을 호출하기 위해 서버 <command> 등의 리소스 command 구조체를 업데이트하는 예시적인 메시지 흐름을 나타낸 흐름도이다. 업데이트를 개시하기 위해, NA(즉, 발행자)는 M2M 서버에 대해 RESTful 메소드 UPDATE를 발행할 수 있다. 이 RESTful 메소드 UPDATE는, 서브리소스 execResume(예컨대, .../<command>/exec-Resume)을 명시하는 것과 함께, <requestInstance> 식별자를 포함할 수 있다. 다른 대안으로서, RESTful 메소드 UPDATE는 M2M 서버로부터 송신된 Response를 통해(도 29m) 또는 리소스 <requestInstance>의 속성으로부터 그를 검색한 후에(도 29n) 획득된 execResume 식별자를 포함할 수 있다.
이 RESTful 메소드 UPDATE에 응답하여, M2M 서버는 RESTful 메소드 UPDATE의 수신을 확인 응답하기 위해 ACK/NACK 메시지(Response로서 도시됨)를 발행자로 송신할 수 있다. 발행자에 의한 ACK/NACK 메시지의 수신이 없는 것은 M2M 서버에 의한 RESTful 메소드 UPDATE의 확인 응답이 없는 것을 나타낼 수 있다.
M2M 서버는 이어서 서버 <command>의 속성 및/또는 서브리소스에 따라 비RESTful 명령의 명령 실행 재개를 호출할 수 있다. M2M 서버는, 명령 실행 재개를 호출하는 것의 일부로서, 다수의 함수를 수행할 수 있다. 이들 함수는, 예를 들어, 리소스 <requestInstance>에 의해 식별된 명령 실행 재개를 일시정지된 비RESTful 명령의 명령 실행 재개("비RESTful 재개 명령")를 호출하는 비RESTful 명령으로 변환하는 것을 포함할 수 있다. 이들 함수는 또한 리소스 <requestInstance>에 의해 식별된 명령과 비RESTful 재개 명령 사이에서 매핑된 속성, 파라미터 및/또는 인수를 준비하는 함수를 포함할 수 있다.
명령 실행 재개를 호출하는 함수를 수행한 후에, M2M 서버는 M2M 디바이스 및/또는 M2M GW에서 명령 실행 재개를 호출하기 위해 Request를 이러한 M2M 디바이스 및/또는 M2M GW로 송신할 수 있다. Request는 비RESTful 재개 명령을 포함할 수 있다. Request는 또한 비RESTful 재개 명령을 수행하기 위한 매핑된 속성, 파라미터 및 인수 중 임의의 것을 포함할 수 있다.
Request에 응답하여, M2M 디바이스 및/또는 M2M GW는 비RESTful 재개 명령을 실행할 수 있다. M2M 디바이스 및/또는 M2M GW는 Command-execution Response를 송신할 수 있다. 이 Command-execution Response는 결과(있는 경우)를 포함할 수 있다. M2M 서버는 결과를 추출하고, 나중의 검색을 위해, 리소스 <requestInstance>의 execResult 서브리소스에 저장할 수 있다. 다른 대안으로서 및/또는 그에 부가하여, M2M 서버는 NA Response에서 결과를 송신할 수 있다. 결과(있는 경우)를 획득한 후에, NA는 이를 처리할 수 있다.
Command-execution Response는 또한 M2M 디바이스 및/또는 M2M GW가 비RESTful 재개 명령의 명령 실행 재개를 성공적으로 수행했는지 비RESTful 재개 명령의 명령 실행 재개를 수행하는 데 실패했는지를 나타내는 표시(예컨대, 코드)를 포함할 수 있다. 이 표시는 성공적인 명령 실행 재개를 나타내는 하나의 값 및 실패를 나타내는 다른 값일 수 있다. 다른 대안으로서, Response는 M2M 디바이스 및/또는 M2M GW가 명령 실행 재개를 성공적으로 수행했다는 것을 나타내는 제1 표시(예컨대, 코드), 그리고 M2M 디바이스 및/또는 M2M GW가 명령 실행 재개를 수행하는 데 실패했다는 것을 나타내는 제2 표시(예컨대, 코드)를 포함할 수 있다. 다른 대안으로서, M2M 디바이스 및/또는 M2M GW가 명령 실행 재개를 성공적으로 수행한 경우에만, M2M 디바이스 및/또는 M2M GW는 Command-execution Response를 발행할 수 있다.
비록 도시되어 있지 않지만, M2M 서버는 M2M 디바이스 및/또는 M2M GW가 비RESTful 명령의 명령 실행 재개를 수행하는 데 실패할 때에 리소스 <requestInstance>를 삭제할 수 있다. M2M 서버는 또한, M2M 디바이스 및/또는 M2M GW가 비RESTful 일시정지 명령의 명령 실행 재개를 수행하는 데 실패했다고 통보받은 것에 응답하여, 서버 <command> 및/또는 하나 이상의 서버 <commands>를 삭제할 수 있다.
이제 도 29o를 참조하면, 비RESTful 명령을 수행하는 데 사용하기 위한 정보로 <requestInstance> 등의 리소스 command 구조체를 업데이트하는 예시적인 메시지 흐름을 나타낸 메시지 흐름도가 도시되어 있다. 도 29d의 메시지 흐름과 같이, 도 29o의 메시지 흐름은 비RESTful 명령을 수행하는 데 사용될 수 있는 정보(예컨대, 속성, 파라미터 및/또는 인수 중 임의의 것)로 <requestInstance> 등의 리소스 command 구조체의 요소를 채우기 위해 RESTful 메소드 UPDATE를 사용할 수 있다.
도시된 바와 같이, NA(즉, 발행자)는 업데이트를 개시하기 위해 M2M 서버에 대해 RESTful 메소드 UPDATE를 발행할 수 있다. RESTful 메소드 UPDATE는 <requestInstance> 식별자와 <requestInstance>의 속성 및/또는 서브리소스를 채우기 위한 정보(예컨대, 속성, 파라미터 및/또는 인수)를 포함할 수 있다.
RESTful 메소드 UPDATE의 수신 후에, M2M 서버는 <requestInstance> 식별자를 사용하여 <requestInstance>를 찾아낸다. 그 후에, M2M 서버는 이러한 <requestInstance>의 속성 및/또는 서브리소스를 제공된 정보로 채울 수 있다. 임의의 주어진 속성 및/또는 서브리소스를 채우기 위한 정보가 제공되지 않는 경우, M2M 서버는 이러한 속성 및/또는 서브리소스를 처음에 생성된 또는 마지막으로 수정된 대로 둘 수 있다(예컨대, 비어 있거나 기본값 속성 및/또는 파라미터를 가짐).
RESTful 메소드 UPDATE에 응답하여, M2M 서버는 Response를 발행자로 송신할 수 있다. M2M 서버는, 도시된 바와 같이, <requestInstance>를 업데이트한 후에 Response를 송신할 수 있다. 다른 대안으로서, M2M 서버는 <requestInstance>의 업데이트 동안 Response를 송신할 수 있다. M2M 서버는 또한 RESTful 메소드 UPDATE의 수신을 확인 응답하기 위해 ACK/NACK 메시지(도시 생략)를 발행자로 송신할 수 있다. (예컨대, 특정의 시간 내에) 발행자에 의한 ACK/NACK 메시지의 수신이 없는 것은 M2M 서버에 의한 RESTful 메소드 UPDATE의 확인 응답이 없는 것을 나타낼 수 있다.
Response는 M2M 서버가 <requestInstance>를 성공적으로 업데이트했는지 업데이트하는 데 실패했는지를 나타내는 표시(예컨대, 코드)를 포함할 수 있다. 이 표시는 성공적인 업데이트를 나타내는 하나의 값 및 실패를 나타내는 다른 값일 수 있다. 다른 대안으로서, Response는 M2M 서버가 <requestInstance>를 성공적으로 업데이트했다는 것을 나타내는 제1 표시(예컨대, 코드), 및 <requestInstance>를 업데이트하는 데 실패했다는 것을 나타내는 제2 표시(예컨대, 코드)를 포함할 수 있다. 다른 대안으로서, M2M 서버는 M2M 서버가 <requestInstance>를 성공적으로 업데이트한 경우에만 Response를 발행할 수 있다.
이 Response는 또한 <requestInstance> 식별자 및/또는 업데이트된 속성 및/또는 서브리소스 정보를 포함할 수 있다. Response는 속성 및/또는 서브리소스를 업데이트하는 데 사용된 정보 또는 동일한 것을 나타내는 확인을 추가로 포함할 수 있다.
도 29p는 <requestInstance> 등의 리소스 command 구조체로부터 정보를 검색하는 예시적인 메시지 흐름을 나타내는 메시지 흐름도이다. 검색을 개시하기 위해, NA(즉, 발행자)는 M2M 서버에 대해 RESTful 메소드 RETRIEVE를 발행한다. RESTful 메소드 RETRIEVE는 <requestInstance> 식별자를 포함할 수 있다.
RESTful 메소드 RETRIEVE의 수신 후에, M2M 서버는 <requestInstance>를 찾아내기 위해 <requestInstance> 식별자를 사용할 수 있다. 일단 찾아내면, M2M 서버는 검색가능 정보(예컨대, 속성, 파라미터 및/또는 인수)(이후부터 "검색된 속성 정보" 및/또는 "검색된 서브리소스 정보"라고 함)를 가지는 <requestInstance>의 속성 및/또는 서브리소스로부터 이러한 검색가능 정보를 질의하고 획득할 수 있다. 검색된 속성 및/또는 검색된 서브리소스 정보는, 예를 들어, 저장된 execDisable, execPause 및 execResume 식별자 중 임의의 것 및/또는 execStatus 및 execResults 등의 다른 속성 및/또는 서브리소스로부터의 정보 중 임의의 것을 포함할 수 있다.
검색된 속성 및/또는 검색된 서브리소스 정보를 획득한 후에, M2M 서버는 Response를 NA로 송신할 수 있다. 이 Response는 <requestInstance> 식별자 및 검색된 속성 및/또는 검색된 서브리소스 정보를 포함할 수 있다.
대안으로서, RESTful 메소드 RETRIEVE는 이러한 검색가능 정보를 가지는 <requestInstance>의 속성 및/또는 서브리소스로부터 검색가능 정보의 하나 이상의 선택 부분을 검색하는 데 사용될 수 있다. 이것을 용이하게 해주기 위해, RESTful 메소드 RETRIEVE는 검색가능 정보의 선택 부분을 가지는 서버 <command>의 속성 및/또는 서브리소스에 할당된 각각의 노드의 식별자를 포함할 수 있다. 식별자(또는 2개 이상인 경우, 식별자들)를 사용하여, M2M 서버는 선택되는 검색된 속성 및/또는 검색된 서브리소스 정보를 찾아내고, 질의하며 획득할 수 있다. M2M 서버는 이어서 선택되는 검색된 속성 및/또는 검색된 서브리소스 정보를 포함하는 Response를 NA로 송신할 수 있다.
비록 도시되어 있지 않지만, M2M 서버는 또한 RESTful 메소드 RETRIEVE의 수신을 확인 응답하기 위해 ACK/NACK 메시지를 발행자로 송신할 수 있다. (예컨대, 특정의 시간 내에) 발행자에 의한 ACK/NACK 메시지의 수신이 없는 것은 M2M 서버에 의한 RESTful 메소드 RETRIEVE의 확인 응답이 없는 것을 나타낼 수 있다.
도 29q는 <requestInstance> 등의 리소스 command 구조체를 삭제하는 예시적인 메시지 흐름을 나타내는 메시지 흐름도이다. 삭제를 개시하기 위해, 발행자는 M2M 서버에 대해 RESTful 메소드 DELETE를 발행할 수 있다. 발행자는 NA, M2M 디바이스 또는 M2M GW일 수 있다. M2M 디바이스 및/또는 M2M GW는 재부팅, 비RESTful 명령의 취소, 등록 해제 등에 응답하여 RESTful 메소드 DELETE를 발행할 수 있다.
RESTful 메소드 DELETE는 <requestInstance> 식별자를 포함할 수 있다. 다른 대안으로서, RESTful 메소드 DELETE는 그 아래에 <requestInstance> 인스턴스의 모음이 생성되어 있는 리소스(예컨대, <requestInstance>)에 할당된 노드의 식별자(이후부터, "<requestInstance> 식별자"라고 함)를 포함할 수 있다.
RESTful 메소드 DELETE의 수신 후에, M2M 서버는 <requestInstance> 또는 <requestInstances>를 찾아내어 삭제하기 위해, 각각, <requestInstance> 식별자 또는 <requestInstances> 식별자를 사용할 수 있다. 이것은 <requestInstance> 또는, <requestInstances>에 대해, 이러한 <requestInstances>의 각각의 <requestInstance>의 모든 속성 및/또는 서브리소스를 삭제하는 것을 포함할 수 있다.
RESTful 메소드 DELETE에 응답하여, M2M 서버는 Response를 발행자로 송신할 수 있다. M2M 서버는, 도시된 바와 같이, <requestInstance> 또는 <requestInstances>를 삭제한 후에 Response를 송신할 수 있다. 다른 대안으로서, M2M 서버는 <requestInstance> 또는 <requestInstances>의 삭제 동안 Response를 송신할 수 있다. M2M 서버는 또한 RESTful 메소드 DELETE의 수신을 확인 응답하기 위해 ACK/NACK 메시지(도시 생략)를 발행자로 송신할 수 있다. 발행자에 의한 ACK/NACK 메시지의 수신이 없는 것은 M2M 서버에 의한 RESTful 메소드 DELETE의 확인 응답이 없는 것을 나타낼 수 있다.
Response는 M2M 서버가 <requestInstance> 또는 <requestInstances>를 성공적으로 삭제했는지 삭제하는 데 실패했는지를 나타내는 표시(예컨대, 코드)를 포함할 수 있다. 이 표시는 성공적인 삭제를 나타내는 하나의 값 및 실패를 나타내는 다른 값일 수 있다. 다른 대안으로서, Response는 M2M 서버가 <requestInstance> 또는 <requestInstances>를 성공적으로 삭제했다는 것을 나타내는 제1 표시(예컨대, 코드), 및 <requestInstance> 또는 <requestInstances>를 삭제하는 데 실패했다는 것을 나타내는 제2 표시(예컨대, 코드)를 포함할 수 있다. 다른 대안으로서, M2M 서버는 M2M 서버가 <requestInstance> 또는 <requestInstances>를 성공적으로 삭제한 경우에만 Response를 발행할 수 있다.
이제 도 29r를 참조하면, 서버 <command>, 서버 <commands> 및/또는 <requestInstance> 등의 리소스 command 구조체를 삭제하는 예시적인 메시지 흐름을 나타낸 메시지 흐름도가 도시되어 있다. 도 29r의 메시지 흐름은 도 29c의 메시지 흐름과 도 29i(또는 도 29j)의 메시지 흐름의 조합 또는 도 29q의 메시지 흐름과 도 29i(또는 도 29j)의 메시지 흐름의 조합과 유사하다. 도시된 바와 같이, 발행자가 M2M 서버에 대해 RESTful 메소드 DELETE를 발행할 때, M2M 서버는 임의의 <requestInstance>가 명령 실행 또는 명령 실행 일시정지를 위해 사용되는지를 판정하고, 그러면 M2M 서버는 이러한 <requestInstance>를 삭제하기 전에 <requestInstance>의 명령 실행 취소를 수행할 수 있다. M2M 서버는 도 29i 또는 도 29j의 메시지 흐름에 따라 명령 실행 취소를 수행할 수 있다.
이상의 내용에 부가하여, M2M 서버는, RESTful 메소드 CREATE 또는 RESTful 메소드 DELETE를 발행하는 일 없이, 서버 <command> 또는 다른 리소스 command 구조체를 생성 및/또는 삭제할 수 있다.
예시적인 게이트웨이-기반 M2M ( machine - to - machine ) 디바이스 관리
일 실시예에 따르면, 도 30a는 OMA GwMO "투명" 모드를 이용함으로써 M2M GW(G')를 통해 D-유형 ETSI M2M 디바이스를 관리하는 예시적인 아키텍처를 나타낸 것이다. 도 30a를 참조하면, NREM은 GwMO-관련 인터페이스 및 구성요소를 사용하여 GREM으로부터 디바이스 정보를 가져오고, GREM은 차례로 이 작업을 수행하라고 GwMO 인터페이스를 통해 DREM에게 통보한다. 이어서, NREM은 OMA DM 프로토콜 - 메시지 교환을 위한 클라이언트-서버 상호작용 모델 - 을 사용하여 DREM에게 직접 통보한다. 주목할 점은, "투명" 모드에서, GREM이 디바이스를 관리하기 위해 OMA DM 프로토콜을 지원할 필요가 없다는 것이다.
일 실시예에 따르면, 도 30b는 ETSI M2M xREM의 예시적인 아키텍처를 나타낸 것이다. 도 30b를 참조하면, xREM은 기능적 서브모듈로 분할된다. 예를 들어, REM 서버는 (OMA DM 또는 ACS에서의 DM 서버와 같이) 디바이스 관리에서 서버 역할을 한다. REM 클라이언트는 (OMA DM 또는 CPE에서의 DM 클라이언트와 같이) 디바이스 관리에서 클라이언트 역할을 한다. REM 프록시 구성요소는 (NREM에서의) REM 프록시 서버 및 (DREM에서의) REM 프록시 클라이언트에 각각 지시하는 GREM에만 참여한다. REM 프록시 서버는 GW 배후에 있는 디바이스의 정보를 얻도록 REM 프록시 구성요소에 지시하는 데 사용되는 NREM에 참여한다. REM 프록시 클라이언트는 디바이스 정보를 GW에 보고하기 위해 - 디바이스 정보는 궁극적으로 NREM으로 전달됨 - REM 프록시 구성요소에 응답하는 데 사용되는 DREM에 참여한다.
프록시 모드에서, M2M GW는 "중간자(man-in-the-middle)"처럼 기능할 수 있다. 이는, OMA GwMO1.0을 이용하는 예시적인 아키텍처를 나타낸 도 31a에 도시된 바와 같이, GwMO 및 DM 클라이언트 및 DM 서버 모두를 지원할 수 있다. 이 모드에서, NREM은 DREM과 직접 통신하지 않고, 그 대신에 GREM에 의해 변환 및 중계된다. DREM에게, GREM은 서버처럼 보이고, NREM에게, GREM은 클라이언트처럼 거동한다. 이 모드는 M2M GW에 보다 많은 특징 및 기능을 부가한다. 예시적인 이점은 명령 팬아웃(command fan-out) 및 응답 통합(response aggregation) 등의 보다 많은 부가 가치 서비스, 또한 M2M 코어에서의 보다 낮은 트래픽 부하 및 제약된 M2M 디바이스, 특히 슬립 상태의 노드를 관리하는 데 보다 효율적임을 포함한다. 도 31b는 이 모드에 대한 xREM의 예시적인 아키텍처를 나타낸 것이다.
일 실시예에 따르면, M2M 디바이스(D')는 ETSI M2M 서비스 능력을 갖지 않을 수 있다. 이들이 OMA DM 클라이언트 기능을 갖지 않고, 다른 비OMA 디바이스 관리 프로토콜을 갖는 것으로 가정될 수 있다. 그 결과, M2M GW는 OMA 프로토콜과 다른 관리 프로토콜 간에 변환하기 위해 "적응" 모드를 채택할 수 있다. 도 32a는 OMA GwMO1.0을 이용하는 예시적인 아키텍처를 나타낸 것이다. 도 32b는 ETSI M2M xREM의 예시적인 아키텍처를 나타낸 것이다. "프록시" 모드와 비교하여, dIa 인터페이스 또는 다른 NDM-1 인터페이스를 통한 M2M GW와 M2M 디바이스 간의 상호작용을 위해 어떤 비OMA 관리 프로토콜(SNMP 등)이 이용될 수 있다. 주목할 점은, 프로토콜 변환이 관리 명령 매핑/변환은 물론 관리 트리 구조(또는 리소스) 매핑/변환 등도 말한다는 것이다. D'-유형 디바이스가 실제로 OMA DM 클라이언트 기능을 가지는 경우, "투명" 및 "프록시" 모드가 또한 적용될 수 있다.
일 실시예에 따르면, d-유형 비-ETSI M2M 디바이스가 상이한 관리 프로토콜을 사용할 수 있는 것으로 가정될 수 있다. 그 결과, M2M GW는 이들을 관리하기 위해 "적응" 모드를 사용할 수 있다. 도 33a 및 도33b에 도시된 아키텍처는 도 32a 및 도 32b의 아키텍처와 유사하다. 주목할 점은, d-유형 디바이스가 ZigBee 코디네이터(ZigBee coordinator) 등의 비-ETSI M2M GW - 이를 통해 비ETSI M2M 영역 네트워크가, ETSI M2M 서비스 능력을 사용하고 그에 액세스하여, 서로 연결될 수 있음 - 일 수 있다는 것이다.
일 실시예에서, 도 34는 OMA GwMO를 이용하는 GW-기반 디바이스 관리의 다이어그램을 나타낸 것이다. 도 34에 도시된 바와 같이, 단일의 M2M GW가 다수의 M2M 영역 네트워크를 상이한 유형의 M2M 디바이스와 연결시킬 수 있다. M2M GW는 상이한 영역 네트워크에 대해 투명, 프록시 또는 적응 관리 모드를 이용할 수 있다.
도 30 내지 도 34 모두에서, 추가의 OMA GwMO 및 DM 논리 엔터티(OMA DM 서버 등)가 xREM의 일부일 필요는 없고, 그 대신에, xREM 외부에 있는 개별적인 엔터티일 수 있다. 그렇지만, 본 명세서에 개시되어 있는 아키텍처가 또한 적용될 수 있다. 예를 들어, 도 35는 OMA DM과 M2M GW의 부분적으로 엄격한 통합을 위한 예시적인 아키텍처를 나타낸 것이다. 도 36은 OMA DM과 M2M GW의 느슨한 통합을 위한 예시적인 아키텍처를 나타낸 것이다.
M2M 영역 네트워크 및 M2M 게이트웨이 배후에 있는 M2M 디바이스를 관리하는 예시적인 데이터 모델
이하에서 더 상세히 기술되는 바와 같이, M2M(machine-to-machine communications) 영역 네트워크 및 M2M 게이트웨이 배후에 있는 M2M 디바이스를 관리하는 관리 객체(MO). M2M 영역 네트워크 관리는 디바이스 인벤토리 및 구성 관리, 영역 네트워크 구성 관리, 영역 네트워크 성능 관리, 및 디바이스의 그룹 관리 등의 기능을 제공할 수 있다. 이것은 응용 프로그램(A), M2M 직접 디바이스(direct device)(D), M2M 로컬 디바이스(local device)(d-유형, D'-유형, 또는 D-유형 디바이스), 및 M2M 게이트웨이(G)를 포함할 수 있다.
관리 객체(MO)는 M2M 게이트웨이에 의해 M2M 영역 네트워크를 관리하기 위해 정의될 수 있다. 한가지 이러한 MO는 영역 네트워크 정보 및 구성에 대한 관리 객체일 수 있는 etsiAreaNwkInfo 리소스일 수 있다. 다른 MO은 M2M 로컬 디바이스 인벤토리에 대한 MO일 수 있는 etsiAreaNwkDeviceInventory 리소스일 수 있다. M2M 로컬 디바이스 그룹에 대한 관리 객체는, 예를 들어, etsiAreaNwkDeviceGroups 리소스일 수 있다. M2M 로컬 디바이스의 그룹을 동작시키는 관리 객체는 etsiGroupMgmtOperations 및 etsiAreaNwkGroupOperations 중 임의의 것일 수 있고, M2M 디바이스에 통합된 센서에 대한 관리 객체 리소스는 etsiSensors 리소스일 수 있다.
MO는 상이한 종속 레벨에 구성 및/또는 위치될 수 있다. 예를 들어, MO는 M2M 서버에서 <sclBase-of-Server>/scls/<GSCL> 아래의 어딘가에 있는 동일한 자리 표시자의 서브리소스일 수 있다. 예로서, M2M 게이트웨이 배후에 있는 접속된 디바이스를 전체로서 관리하기 위해 <sclBase-of-Server>/scls/<GSCL>/attachedDevices 아래의 mgmtObjs 서브리소스가 생성될 수 있다. MO는, 예를 들어, <sclBase-of-Server>/scls/<GSCL>/attachedDevices/mgmtObjs 아래에 위치될 수 있다. MO는 다른 MO의 서브리소스일 수 있다. 예를 들어, etsiSensors는 <deviceInventory>의 서브리소스일 수 있고, <deviceInventory>는 etsiAreaNwkDeviceInventory의 서브리소스일 수 있다.
도 37에 도시된 바와 같이, 영역 네트워크 정보 및 구성에 대한 MO인 etsiAreaNwkInfo는 하나 이상의 속성 그리고 subscriptions collection 및 <areaNwkInstance> 등의 복수의 서브리소스를 포함할 수 있다. <areaNwkInstance>는 M2M 영역 네트워크의 인스턴스일 수 있다. etsiAreaNwkInfo의 속성은, 예를 들어, expirationTime, accessRightID, searchStrings, creationTime, lastModifiedTime, contentType, moID, originalMO, numOfAreaNwks, 및 description을 포함할 수 있다. numOfAreaNwks 속성은 M2M 영역 네트워크의 수를 나타낼 수 있다. description 속성은 mgmtObj의 텍스트 형식 설명일 수 있다. 속성(및/또는 변수)은 ETSI M2M TS 102 690에 부합할 수 있다. 대안으로서, attributes 및/또는 subscriptions collection은 expirationTime, accessRightID, searchStrings, creationTime, lastModifiedTime, contentType, moID, originalMO, numOfAreaNwks, 및 description을 포함, 유지 및/또는 저장할 수 있다.
도 38a에 도시된 바와 같이, etsiAreaNwkInfo 리소스의 <areaNwkInstance> 서브리소스는 하나 이상의 속성 및 복수의 서브리소스를 포함할 수 있다. <areaNwkInstance> 서브리소스는 (i) M2M 영역 네트워크의 식별자를 가지고 있는 areaNwkID 속성, (ii) M2M 영역 네트워크의 유형, 예컨대, Bluetooth/6LoWPAN, 802.15.4/6LoWPAN, Wi-Fi 네트워크를 명시하는 areaNwkType 속성, (iii) M2M 영역 네트워크의 동작 채널 주파수를 명시하는 workingChannelFrequency 속성, 및 (iv) M2M 영역 네트워크의 주소 모드(예컨대, IPv4, IPv6, Short MAC(medium access control), 또는 Long MAC)를 명시하는 addressMode 속성을 포함할 수 있다.
<areaNwkInstance> 서브리소스의 복수의 서브리소스는 subscription collection, <deviceInstance> 서브리소스, attachedDevices 서브리소스, groups 서브리소스, 6LoWPAN 서브리소스, Wi-Fi 서브리소스, RFID 서브리소스, 및 ZigBee 서브리소스를 포함할 수 있다.
<deviceInstance> 서브리소스는 영역 네트워크 인스턴스에서의 단일 디바이스에 대한 정보를 포함할 수 있다. attachedDevices 서브리소스는 영역 네트워크에의 모든 접속된 디바이스에 대한 자리 표시자일 수 있고, groups 서브리소스는 그룹 동작 또는 동작 팬아웃에 대한 정의된 디바이스 그룹에 대한 자리 표시자일 수 있다. 6LoWPAN 서브리소스는 6LoWPAN 네트워크에 관련된 파라미터를 포함하는 자리 표시자일 수 있는데, 그 이유는 영역 네트워크가 6LoWPAN 네트워크일 때 이러한 정보가 사용될 수 있기 때문이다. Wi-Fi 서브리소스는 Wi-Fi 네트워크에 관련된 파라미터를 포함하는 자리 표시자일 수 있는데, 그 이유는 영역 네트워크가 Wi-Fi 네트워크일 때 이러한 정보가 사용될 수 있기 때문이다. RFID 서브리소스는 RFID 네트워크에 관련된 파라미터를 포함하는 자리 표시자일 수 있는데, 그 이유는 영역 네트워크가 RFID 네트워크일 때 이 정보가 필요할 수 있기 때문이고, ZigBee 서브리소스는 ZigBee 네트워크에 관련된 파라미터를 포함하는 자리 표시자일 수 있는데, 그 이유는 영역 네트워크가 ZigBee 네트워크일 때 이러한 정보가 필요할 수 있기 때문이다. Extensions은 또한 서브리소스로서 포함될 수 있고 확장(extensions)에 대한 자리 표시자를 제공할 수 있다.
<areaNwkInstance> 서브리소스와 연관되어 있는 속성은 (i) 영역 네트워크 인스턴스에서의 디바이스의 수를 나타낼 수 있는 numOfDevices; (ii) 2개의 슬립(sleep) 사이의 간격을 나타낼 수 있는 sleeplnterval; (iii) 각각의 슬립의 지속 시간을 나타낼 수 있는 sleepDuration; (iv) 이 영역 네트워크 <areaNwkInstance> 서브리소스에서의 최대 전송 단위를 나타낼 수 있는 MTU; 및 (v) IETF CoAP 블록 단위 전송에서 사용되는 블록 크기를 나타낼 수 있는 blockSize를 포함할 수 있다. blockSize는 영역 네트워크 <areaNwkInstance> 서브리소스가 제약된 응용 프로그램 프로토콜(CoAP 프로토콜)을 지원할 때 도움이 될 수 있다. sleeplnterval 속성은 일반적인 시간 간격으로서 사용될 수 있고, 이를 통해 M2M 서버는 특정의 보고 또는 응답을 주기적으로, 예를 들어, 매 sleeplnterval 시간 단위마다, 다시 송신하라고 M2M 디바이스 및/또는 M2M 게이트웨이에 지시할 수 있다.
도 38b에 도시된 바와 같이, 6LoWPAN 서브리소스는 subscriptions 서브리소스, subscription 및 6LoWPAN에서의 어드레싱, 라우팅 및 이웃 발견 중 임의의 것에 관련된 복수의 속성을 가질 수 있다. 복수의 속성은 (i) 영역 네트워크의 IP 주소 프리픽스를 명시하는 ipAddrPrefix 속성, 및 (ii) M2M 영역 네트워크의 라우팅 모드를 명시하는 routingMode 속성을 포함할 수 있다. 6LoWPAN 네트워크에 대해, routingMode 속성은 라우팅 모드를 메쉬 언더(mesh-under) 또는 루트 오버(route-over)로 명시할 수 있다.
복수의 속성은 또한 (i) 변경을 대비하여 헤더 압축 컨텍스트 정보(header compression context information)를 계속 배포하는 최소 시간을 명시하는 minContextChangeDelay 속성; (ii) 송신될 비요청 라우터 광고(unsolicited Router Advertisements)의 최대 수를 저장 및/또는 명시하는 maxRtrAdvertisements 속성, (iii) 모든 노드의 멀티캐스트 주소로 송신되는 2개의 연속적인 라우터 광고 사이의 최소 간격을 명시하는 minDelayBetweenRas 속성; (iv) 수신된 라우터 요청(Router Solicitation) 메시지에 대한 응답으로서 라우터 광고(Router Advertisement) 메시지를 송신하는 최대 지연을 명시하는 maxRaDelayTime 속성; (v) 시험적인 이웃 캐시 대한 타이머를 저장 및 제공하는 tentativeNceLifetime 속성; (vii) 중복 주소 검출(Duplicate Address Detection) 메시지에 대한 홉 한계 값(hop limit value)을 저장 및/또는 명시하는 hopLimit 속성; (viii) 처음 maxRtrSolications개의 라우터 요청의 초기 재전송을 위한 구간을 저장 및/또는 명시하는 rtrSolicitationlnterval 속성; (ix) rtrSolicitationInterval에 의해 정의되는 초기 재전송의 횟수를 저장 및/또는 명시하는 maxRtrSolicitations 속성; 및 (x) 디바이스가 초기 재전송 이후 이진 지수 백오프(binary exponential backoff)를 사용할 수 있기 때문에 라우터 요청에 대한 최대 재전송 구간을 저장 및/또는 명시하는 maxRtrSolicitationInterval 속성을 포함할 수 있다. hopLimit, rtrSolicitationlnterval, maxRtrSolicitations 및 maxRtrSolicitationlnterval 속성은 디바이스에 적용가능할 수 있다. 다른 파라미터는 디바이스 및 M2M 게이트웨이 둘 다에 적용가능할 수 있다.
도 38c에 도시된 바와 같이, etsiAreaNwkInfo 리소스의 <areaNwkInstance> 서브리소스는 하나 이상의 속성 및 subscriptions 서브리소스를 포함할 수 있다. <areaNwkInstance> 서브리소스는 (i) M2M 영역 네트워크의 식별자를 가지고 있는 areaNwkID 속성, (ii) M2M 영역 네트워크의 유형, 예컨대, Bluetooth/6LoWPAN, 802.15.4/6LoWPAN, Wi-Fi 네트워크를 명시하는 areaNwkType 속성, (iii) M2M 영역 네트워크의 동작 채널 주파수를 명시하는 workingChannelFrequency 속성, 및 (iv) M2M 영역 네트워크의 주소 모드(예컨대, IPv4, IPv6, Short MAC(medium access control), 또는 Long MAC)를 명시하는 addressMode 속성, (v) 6LoWPAN 속성, Wi-Fi 속성, RFID 속성, ZigBee 속성을 포함할 수 있다.
6LoWPAN 속성은 6LoWPAN 네트워크에 관련된 파라미터(예컨대, 영역 네트워크가 6LoWPAN 네트워크일 때 사용될 수 있는 정보)를 포함하는 자리 표시자일 수 있다. Wi-Fi 속성은 Wi-Fi 네트워크에 관련된 파라미터(예컨대, 영역 네트워크가 Wi-Fi 네트워크일 때 사용될 수 있는 정보)를 포함하는 자리 표시자일 수 있다. RFID 속성은 RFID 네트워크에 관련된 파라미터를 포함하는 자리 표시자일 수 있고, ZigBee 속성은 ZigBee 네트워크에 관련된 파라미터를 포함하는 자리 표시자일 수 있다.
그에 부가하여, <areaNwkInstance> 서브리소스는 특정 유형의 영역 네트워크에 관련된 추가의 속성을 가질 수 있다. 예를 들어, M2M 영역 네트워크가 6LoWPAN 네트워크인 경우, <areaNwkInstance> 서브리소스는 6LoWPAN에서의 어드레싱, 라우팅 및/또는 이웃 발견에 관련된 다수의 속성을 포함할 수 있다. 복수의 속성은 (i) ipAddrPrefix 속성, (ii) routingMode 속성; (iii) minContextChangeDelay 속성; (iv) maxRtrAdvertisements 속성; (vi) minDelayBetweenRas 속성, (vii) maxRaDelayTime 속성, (viii) tentativeNceLifetime 속성, (ix) hopLimit 속성, (x) rtrSolicitationlnterval 속성, (xi) rtrSolicitationlnterval에 의해 정의되는 초기 재전송의 횟수를 저장 및/또는 명시하는 maxRtrSolicitations 속성, 및 (xii) maxRtrSolicitationlnterval 속성을 포함할 수 있다. hopLimit, rtrSolicitationlnterval, maxRtrSolicitations 및 maxRtrSolicitationlnterval 속성은 디바이스에 적용가능할 수 있다. 다른 파라미터는 디바이스 및 M2M 게이트웨이 둘 다에 적용가능할 수 있다.
도 39에 도시된 바와 같이, etsiAreaNwkDeviceInventory MO는 (i) M2M 게이트웨이와 접속되어 있는 각각의 활성 디바이스에 대한 개별적인 <deviceInstance> 정보의 모음을 포함할 수 있는 <deviceInstance> 서브리소스; (ii) 각각의 영역 네트워크를 식별해줄 수 있는 <areaNwkInstance> 서브리소스; (iii) 정의된 디바이스 그룹에 대한 자리 표시자를 제공할 수 있는 groups 서브리소스; 및 (iv) subscriptions collection 서브리소스를 비롯한 서브리소스를 포함할 수 있다. subscriptions collection 서브리소스는 expirationTime, accessRightID, searchStrings, creationTime, lastModifiedTime, FSS 형식으로 포함되어 있을 수 있는 contentType, moID, originalMO, description(예컨대, mgmtObj의 텍스트 형식 설명), 및 M2M 게이트웨이와 접속되어 잇는 디바이스의 수인 numOfDevices 등의 속성을 포함할 수 있다.
동일한 M2M 게이트웨이 아래의 M2M 영역 네트워크는 단일의 etsiAreaNwkDeviceInventory 서브리소스에 대응할 수 있거나, 각각의 영역 네트워크는 그 자신의 etsiAreaNwkDeviceInventory 서브리소스를 가질 수 있다. etsiAreaNwkDeviceInventory 서브리소스는 etsiAreaNwkInfo 서브리소스에 종속되어 있을 수 있다. 대안으로서, etsiAreaNwkDeviceInventory MO는 <areaNwkInstance> 서브리소스 및/또는 groups 서브리소스를 포함하지 않을 수 있다.
도 40a에 도시된 바와 같이, 각각의 <deviceInstance>는 deviceGroupsList 등의 디바이스가 속해 있는 그룹의 식별자의 목록, 예를 들어, 이 디바이스 상의 D'A 또는 DA 등의 모든 응용 프로그램의 응용 프로그램 식별자의 그룹인 deviceApplicationsList, 이웃 노드의 식별자의 목록인 deviceNeighborsList, 배터리 정보인 etsiBattery, 메모리 정보인 etsiMemory, 및 센서/작동기 정보인 etsiSensor, 6LoWPAN 네트워크에 관련된 파라미터를 포함하는 자리 표시자를 제공할 수 있는 6LoWPAN, Wi-Fi 네트워크에 관련된 파라미터를 포함하는 자리 표시자를 제공할 수 있는 Wi-Fi, RFID 네트워크에 관련된 파라미터를 포함하는 자리 표시자를 제공할 수 있는 RFID, ZigBee 네트워크에 관련된 파라미터를 포함하는 자리 표시자를 제공할 수 있는 ZigBee, 및 확장(extensions)에 대한 자리 표시자일 수 있는 extensions을 포함할 수 있다.
이 그룹은, 예를 들어, ETSI TS 102 609에 기재되어 있는 것과 같은 표준 그룹 리소스를 제공할 수 있다. <deviceInstance>는 디바이스의 유형일 수 있는 deviceType; 디바이스 식별자일 수 있는 deviceID; 디바이스의 주소 유형일 수 있는 addressType; 디바이스가 속해 있는 M2M 영역 네트워크의 식별자를 포함할 수 있는 areaNwkID; M2M 영역 네트워크 내부에서 사용되는 디바이스의 내부 IP 주소일 수 있는 internal address; 및 M2M 영역 네트워크 외부에서 사용되는 디바이스의 IP 주소일 수 있는 external address 등의 속성을 포함할 수 있다. 이 주소는 포트 번호가 M2M 게이트웨이에서의 주소 변환에서 사용되는 경우 포트 정보를 포함할 수 있다. 게다가, 2개의 슬립 사이의 간격인 sleeplnterval, 각각의 슬립의 지속 시간인 sleepDuration, 디바이스의 상태인 status[슬립 중(sleeping) 또는 어웨이크(awake) 등], 영역 네트워크에서의 최대 전송 단위(maximum transmission unit)를 포함할 수 있는 MTU, 및 IETF CoAP 블록 단위 전송에서 사용되는 블록 크기를 포함할 수 있는 blockSize를 포함할 수 있다.
도 40b에 도시된 바와 같이, 각각의 <deviceInstance>는 deviceGroupList 등의 디바이스가 속해 있는 그룹의 식별자의 목록, 예를 들어, 이 디바이스 상의 D'A 또는 DA 등의 모든 응용 프로그램의 응용 프로그램 식별자의 그룹인 deviceApplicationList, 이웃 노드의 식별자의 목록인 deviceNeighborList, 배터리 정보인 etsiBattery, 메모리 정보인 etsiMemory, 및 센서/작동기 정보인 etsiSensor를 포함할 수 있다. subscription collection은 디바이스의 유형일 수 있는 deviceType; 디바이스 식별자일 수 있는 deviceID; 디바이스의 주소 유형일 수 있는 addressType; 디바이스가 속해 있는 M2M 영역 네트워크의 식별자를 포함할 수 있는 areaNwkID; M2M 영역 네트워크 내부에서 사용되는 디바이스의 내부 IP 주소일 수 있는 internal address; 및 M2M 영역 네트워크 외부에서 사용되는 디바이스의 IP 주소일 수 있는 external address 등의 속성을 포함할 수 있다. 이 주소는 포트 번호가 M2M 게이트웨이에서의 주소 변환에서 사용되는 경우 포트 정보를 포함할 수 있다. 게다가, 2개의 슬립 사이의 간격인 sleepInterval, 각각의 슬립의 지속 시간인 sleepDuration, 디바이스의 상태인 status(슬립 중 또는 어웨이크 등), 송신될 비요청 라우터 광고의 최대 수인 maxRtrAdvertisements, 모든 노드의 멀티캐스트 주소로 송신되는 2개의 연속적인 라우터 광고 사이의 최소 간격인 minDelayBetweenRas, 수신된 라우터 요청 메시지에 대한 응답으로서 라우터 광고 메시지를 송신하는 최대 지연인 maxRaDelayTime, 시험적인 이웃 캐시에 대한 타이머인 tentativeNceLifetime, 중복 주소 검출 메시지에 대한 홉 한계 값인 hopLimit, 처음 maxRtrSolications개의 라우터 요청의 초기 재전송에 대한 구간인 rtrSolicitationlnterval, 초기 재전송의 횟수인 maxRtrSolicitations, 및 디바이스가 초기 재전송 이후 이진 지수 백오프를 사용할 수 있기 때문에 라우터 요청에 대한 최대 재전송 구간인 maxRtrSolicitationInterval을 포함할 수 있다.
도 41a에 도시된 바와 같이, etsiAreaNwkDeviceGroups MO는 장치의 그룹을 정의하는 <deviceGroupInstance> 및 subscriptions 등의 서브리소스를 포함할 수 있다. subscription collection 및 attributes는 expirationTime, accessRightID, searchStrings, creationTime, lastModifiedTime, FSS로서 형식 설정되어 있을 수 있는 contentType, moID, originalMO, 및 mgmtObj의 텍스트 형식 설명을 포함하는 description을 포함할 수 있다.
도 41b에 도시된 바와 같이, etsiAreaNwkDeviceGroups MO는 서브리소스 subscriptions 및 다수의 장치 그룹의 모음으로서 정의되는 서브리소스 groups를 포함할 수 있다. etsiAreaNwkDeviceGroups는 expirationTime, accessRightID, searchStrings, creationTime, lastModifiedTime, FFS로서 형식 설정되어 있을 수 있는 contentType, moID, originalMO, 및 mgmtObj의 텍스트 형식 설명을 포함하는 description 등의 속성을 포함할 수 있다.
각각의 서브리소스 <group>은 동일한 그룹에 속해 있는 디바이스의 식별자의 목록을 포함할 수 있다. 그에 부가하여, 디바이스는 다수의 <group> 인스턴스에 속해 있고 그에 존재할 수 있다.
도 42에 도시된 바와 같이, 각각의 <deviceGroupInstance>는 subscriptions 등의 서브리소스를 포함할 수 있고, subscription collection 및 attributes는 expirationTime, accessRightID, searchStrings, creationTime, lastModifiedTime, FSS 형식으로 되어 있을 수 있는 contentType, moID, originalMO, 및 mgmtObj의 텍스트 형식 설명을 포함하는 description을 포함한다. 게다가, 그룹 식별자를 포함할 수 있는 groupID, 그룹 유형을 포함할 수 있는 groupType, 그룹 내의 장치의 수 등의 groupSize, 그룹 내의 장치의 모음으로서 정의되는 members, 및 디바이스가 이 그룹의 멤버일 조건을 명시하는 condition을 포함한다.
도 43a에 도시된 바와 같이, etsiGroupMgmtOperations MO는 그룹에 대해 실행될 동작(operation) 또는 조치(action)를 나타낼 수 있는 <operationInstance> 등의 서브리소스, 및 정의된 디바이스 그룹 - 각각의 디바이스 그룹은 디바이스의 목록을 포함함 - 에 대한 자리 표시자일 수 있고 하나 또는 다수의 <operationInstance>에 의해 동작될 수 있는 groups을 포함할 수 있다. subscription collection 및 attributes는 expirationTime, accessRightID, searchStrings, creationTime, lastModifiedTime, contentType, moID, originalMO, 및 mgmtObj의 텍스트 형식 설명을 포함하는 description을 포함할 수 있다.
M2M 게이트웨이 배후에 있는 M2M 디바이스의 그룹을 관리/동작하는 데 사용되는 것에 부가하여, etsiGroupMgmtOperations은 M2M 서버에 직접 연결되어 있는 M2M 디바이스의 그룹의 동작을 관리하는 데 사용될 수 있다. 이 경우에, etsiGroupMgmtOperations은 <sclBase-of-Server>/scls/mgmtObjs/etsiGroupMgmtOperations 아래에 위치될 수 있다. 대응하는 <operationInstance>는 M2M 디바이스 또는 게이트웨이의 그룹을 등록 해제하는 것, M2M 디바이스 또는 게이트웨이의 그룹을 슬립 모드로 가게 하는 것, M2M 디바이스 또는 게이트웨이의 그룹을 재부팅하는 것, 및 M2M 디바이스 또는 게이트웨이의 그룹에 대해 동일한 소프트웨어/펌웨어 업데이트를 수행하는 것을 포함할 수 있다.
또한, etsiGroupMgmtOperations은 M2M 디바이스 또는 M2M 게이트웨이에서 응용 프로그램의 그룹을 관리하는 데 사용될 수 있다. 이 경우에, etsiGroupMgmtOperations은 <sclBase-of-Server>/scls/<scl>/applications/mgmtObjs/etsiGroupMgmtOperations 아래에 위치될 수 있다. 대응하는 <operationInstance>는 M2M 응용 프로그램의 그룹을 등록 해제하는 것, 및 M2M 응용 프로그램의 그룹에 대해 동일한 소프트웨어/펌웨어 업데이트를 수행하는 것을 포함할 수 있다.
도 43b에 도시된 바와 같이, etsiAreaNwkDeviceGroupOperations MO는 그룹에 대해 실행될 동작(operation) 또는 조치(action)를 나타낼 수 있는 <operationInstance> 등의 서브리소스를 포함할 수 있다. subscription collection 및 attributes는 expirationTime, accessRightID, searchStrings, creationTime, lastModifiedTime, contentType, moID, originalMO, 및 mgmtObj의 텍스트 형식 설명을 포함하는 description을 포함할 수 있다.
도 44a에 도시된 바와 같이, 각각의 <operationInstance>는 subscriptions 등의 서브리소스를 포함할 수 있고, subscription collection 및 attributes는 expirationTime, accessRightID, searchStrings, creationTime, lastModifiedTime, FSS 형식으로 되어 있을 수 있는 contentType, moID, originalMO, 및 mgmtObj의 텍스트 형식 설명을 포함하는 description을 포함한다. <operationInstance>는, 서브리소스로서, <operationInstance>가 실행될 수 있는 그룹의 식별자의 목록일 수 있는 deviceGroupsList를 포함할 수 있는 groups, 및 <operationInstance>의 결과의 모음일 수 있는 execResults을 포함할 수 있고, <resultInstance> 및 subscription을 비롯한 추가의 서브리소스와 속성 aggregatedResult를 가질 수 있다.
<resultInstance>는 단일 디바이스로부터의 결과를 나타낼 수 있고, 서브리소스 subscriptions 및 디바이스 식별자일 수 있는 deviceID, 디바이스 deviceID로부터의 결과일 수 있는 resultValue, 디바이스 deviceID에 대한 <operationInstance>의 상태일 수 있는 execStatus, deviceID에서 <operationInstance>를 시작할 수 있는 execEnable, deviceID에서 <operationInstance>를 일시정지할 수 있는 execPause, deviceID에서 <operationInstance>를 재개할 수 있는 execResume, deviceID에서 <operationInstance>를 중단시킬 수 있는 execDisable, 통합된 결과일 수 있는 aggregatedResult, <operationInstance>에 의해 요구되는 인수를 포함할 수 있고 동작에 특유할 수 있는 execParameters를 비롯한 속성을 가질 수 있다.
게다가, <operationInstance>의 ID(identification)일 수 있고 <operationInstance>가 무엇을 나타내는지를 명시할 수 있는 operationID를 가질 수 있다. groupID는 <operationInstance>가 실행될 수 있는 그룹의 식별자를 제공할 수 있고, groupID는 <operationInstance>가 다수의 정의된 디바이스 그룹에서 실행될 수 있는 경우 다수의 ID를 포함할 수 있다. 다른 대안으로서, 그 다수의 그룹 ID는 deviceGroupsList 리소스에 포함되어 있을 수 있다. execEnable은 groupID 내의 디바이스에서 <operationInstance>를 시작할 수 있다. execPause는 groupID 내의 디바이스에서 <operationInstance>를 일시정지할 수 있고, execResume은 groupID 내의 디바이스에서 <operationInstance>를 재개할 수 있으며, execDisable은 groupID 내의 디바이스에서 <operationInstance>를 중단시킬 수 있고, execStatus는 <operationInstance>의 상태를 제공할 수 있다. 상태는 보류 중, 실행 중, 중단됨, 일시정지됨, 재개됨, 성공적으로 실행된 디바이스의 수, 디바이스 상에서 완료됨 및 성공, 및/또는 실행되지 못한 디바이스의 수를 포함할 수 있다.
도 44b에 도시된 바와 같이, 각각의 <operationInstance>는 subscriptions 등의 서브리소스를 포함할 수 있고, subscription collection 및 attributes는 expirationTime, accessRightID, searchStrings, creationTime, lastModifiedTime, FSS 형식으로 되어 있을 수 있는 contentType, moID, originalMO, 및 mgmtObj의 텍스트 형식 설명을 포함하는 description을 포함한다. 게다가, groupID는 <operation>이 실행될 수 있는 그룹의 식별자를 제공할 수 있고, enable은 <operation>을 시작하기 위해 제공되어 있을 수 있으며, disable은 <operation>을 중단시키기 위해 제공되어 있을 수 있고, results는 <operation>의 결과의 모음을 포함할 수 있으며, aggregatedResult는 통합된 결과를 포함할 수 있다. 각각의 <resultInstance>는 디바이스 식별자를 나타낼 수 있는 deviceID, 및 디바이스 deviceID로부터의 결과일 수 있는 result 등의 2개의 속성을 가질 수 있다.
도 45에 도시된 바와 같이, etsiSensors MO는 센서 인스턴스에 대한 <sensorInstance> 및 expirationTime, accessRightID, searchStrings, creationTime, lastModifiedTime, FSS 형식으로 되어 있을 수 있는 contentType, moID, originalMO, 및 mgmtObj의 텍스트 형식 설명을 포함할 수 있는 description 등의 subscription collection 및 attributes를 포함하는 subscriptions 등의 서브리소스를 포함할 수 있다. etsiSensors는 M2M 서비스 능력을 가지는 D-유형 M2M 디바이스에 적용가능할 수 있다.
도 46에 도시된 바와 같이, <sensorInstance>는 관련 그룹을 갖는 groups 등의 서브리소스를 포함할 수 있다. 예를 들어, 하나의 그룹은 <sensorInstance>을 사용하는 이 디바이스 상의 D'A 또는 DA 응용 프로그램을 나타내는 applicationList일 수 있다. containers는 센서 판독치를 저장할 수 있다. subscription collection 및 attributes는 expirationTime, accessRightID, searchStrings, creationTime, lastModifiedTime, FSS 형식으로 되어 있을 수 있는 contentType, moID, originalMO, 및 mgmtObj의 텍스트 형식 설명을 포함할 수 있는 description을 포함할 수 있다. sensorID는 <sensorInstance>의 식별자를 나타낼 수 있다. sensorType은 temperature, pressure, <sensorInstance>의 제조업체를 정의하는 manufacturer, 및 <sensorInstance>에서 동작가능한 동작을 포함할 수 있는 operations 등의 <sensorInstance>의 유형을 나타낼 수 있다. enable은 센서 판독을 인에이블시키는 것을 포함할 수 있다. 센서가 스위치 센서인 경우, enable은 스위치 온(switch-on)을 의미할 수 있다. enable은 동작 결과를 저장하는 그의 속성으로서 result를 가질 수 있다. disable은 센서 판독을 디스에이블시키는 것을 포함할 수 있다. 센서가 스위치 센서인 경우, disable은 스위치 오프(switch-off)를 의미할 수 있다. disable은 동작 결과를 저장하는 그의 속성으로서 result를 가질 수 있다. 특정의 센서에 대해 다른 동작이 가능할 수 있다.
예시적인 동작 환경
도 47은 M2M 서버(여기서 <scl>임)에 등록되는 다른 D/G를 관리하기 위해 DA 및/또는 GA에 의해 사용되는 관리 객체에 따라 REM을 수행하는 시스템의 예시적인 아키텍처의 블록도이다.
M2M 서버(즉, <scl>)는, 4702에 나타낸 바와 같이, 그의 관리 객체를 D/G에 공지할 수 있다. 이어서, DA/GA가 D/G에서의 이러한 공지된 관리 객체에 액세스할 수 있고, 차례로 M2M 서버에서의 메시지 중계를 통해 다른 D/G를 관리할 수 있다.
도 48a는 하나 이상의 개시된 실시예가 구현될 수 있는 예시적인 통신 시스템(100)의 도면이다. 통신 시스템(100)은 음성, 데이터, 비디오, 메시징, 방송 등과 같은 콘텐츠를 다수의 무선 사용자에게 제공하는 다중 접속 시스템일 수 있다. 통신 시스템(100)은 다수의 무선 사용자가 시스템 자원(무선 대역폭을 포함함)의 공유를 통해 이러한 콘텐츠에 액세스할 수 있게 해줄 수 있다. 예를 들어, 통신 시스템(100)은 CDMA(code division multiple access, 코드 분할 다중 접속), TDMA(time division multiple access, 시분할 다중 접속), FDMA(frequency division multiple access, 주파수 분할 다중 접속), OFDMA(orthogonal FDMA, 직교 FDMA), SC-FDMA(single-carrier FDMA, 단일 반송파 FDMA) 등과 같은 하나 이상의 채널 액세스 방법을 이용할 수 있다.
도 48a에 도시된 바와 같이, 통신 시스템(100)은 WTRU(wireless transmit/receive unit, 무선 송수신 장치)(102a, 102b, 102c, 102d), RAN(radio access network, 무선 액세스 네트워크)(104), 코어 네트워크(106), PSTN(public switched telephone network, 공중 교환 전화망)(108), 인터넷(110), 및 기타 네트워크(112)를 포함할 수 있지만, 개시된 실시예가 임의의 수의 WTRU, 기지국, 네트워크 및/또는 네트워크 요소를 생각하고 있다는 것을 잘 알 것이다. WTRU(102a, 102b, 102c, 102d) 각각은 무선 환경에서 동작하고 및/또는 통신하도록 구성되어 있는 임의의 유형의 장치일 수 있다. 일례로서, WTRU(102a, 102b, 102c, 102d)는 무선 신호를 전송 및/또는 수신하도록 구성될 수 있고, UE(user equipment), 이동국, 고정형 또는 이동형 가입자 장치, 페이저, 휴대폰, PDA(personal digital assistant), 스마트폰, 랩톱, 넷북, 개인용 컴퓨터, 무선 센서, 가전 제품 등을 포함할 수 있다.
통신 시스템(100)은 또한 기지국(114a) 및 기지국(114b)을 포함할 수 있다. 기지국(114a, 114b) 각각은 하나 이상의 통신 네트워크 - 코어 네트워크(106), 인터넷(110) 및/또는 네트워크(112) 등 - 에의 액세스를 용이하게 해주기 위해 WTRU(102a, 102b, 102c, 102d) 중 적어도 하나와 무선으로 인터페이스하도록 구성되어 있는 임의의 유형의 장치일 수 있다. 일례로서, 기지국(114a, 114b)은 BTS(base transceiver station, 기지국 송수신기), 노드-B, eNode B, 홈 노드 B, 사이트 제어기, AP(access point), 무선 라우터 등일 수 있다. 기지국(114a, 114b) 각각이 단일 요소로서 나타내어져 있지만, 기지국(114a, 114b)이 임의의 수의 상호연결된 기지국 및/또는 네트워크 요소를 포함할 수 있다는 것을 잘 알 것이다.
기지국(114a)은 다른 기지국 및/또는 네트워크 요소 - BSC(base station controller, 기지국 제어기), RNC(radio network controller, 무선 네트워크 제어기), 중계 노드, 기타 등등 - (도시 생략)도 포함할 수 있는 RAN(104)의 일부일 수 있다. 기지국(114a) 및/또는 기지국(114b)은 특정의 지리적 지역 - 셀(도시 생략)이라고 할 수 있음 - 내에서 무선 신호를 전송 및/또는 수신하도록 구성될 수 있다. 셀은 여러 셀 섹터(cell sector)로 추가로 나누어질 수 있다. 예를 들어, 기지국(114a)과 연관된 셀이 3개의 섹터로 나누어질 수 있다. 따라서, 일 실시예에서 기지국(114a)은 3개의 송수신기(즉, 셀의 각각의 섹터마다 하나씩)를 포함할 수 있다. 다른 실시예에서, 기지국(114a)은 MIMO(multiple-input multiple output) 기술을 이용할 수 있고, 따라서, 셀의 각각의 섹터에 대해 다수의 송수신기를 이용할 수 있다.
기지국(114a, 114b)은 임의의 적당한 무선 통신 링크[예컨대, RF(radio frequency, 무선 주파수), 마이크로파, IR(infrared, 적외선), UV(ultraviolet, 자외선), 가시광 등]일 수 있는 공중 인터페이스(116)를 통해 WTRU(102a, 102b, 102c, 102d) 중 하나 이상과 통신할 수 있다. 임의의 적당한 RAT(radio access technology, 무선 액세스 기술)를 사용하여 공중 인터페이스(116)가 설정될 수 있다.
보다 구체적으로는, 앞서 살펴본 바와 같이, 통신 시스템(100)은 다중 접속 시스템일 수 있고, CDMA, TDMA, FDMA, OFDMA, SC-FDMA 등과 같은 하나 이상의 채널 접속 방식을 이용할 수 있다. 예를 들어, RAN(104) 내의 기지국(114a) 및 WTRU(102a, 102b, 102c)는 WCDMA(wideband CDMA, 광대역 CDMA)를 사용하여 공중 인터페이스(116)를 설정할 수 있는 UTRA[UMTS(Universal Mobile Telecommunications System) Terrestrial Radio Access]와 같은 무선 기술을 구현할 수 있다. WCDMA는 HSPA(High-Speed Packet Access, 고속 패킷 액세스) 및/또는 HSPA+(Evolved HSPA)와 같은 통신 프로토콜을 포함할 수 있다. HSPA는 HSDPA(High-Speed Downlink Packet Access, 고속 하향링크 패킷 액세스) 및/또는 HSUPA(High-Speed Uplink Packet Access, 고속 상향링크 패킷 액세스)를 포함할 수 있다.
다른 실시예에서, 기지국(114a) 및 WTRU(102a, 102b, 102c)는 LTE(Long Term Evolution) 및/또는 LTE-A(LTE-Advanced)를 사용하여 공중 인터페이스(116)를 설정할 수 있는 E-UTRA(Evolved UMTS Terrestrial Radio Access)와 같은 무선 기술을 구현할 수 있다.
다른 실시예에서, 기지국(114a) 및 WTRU(102a, 102b, 102c)는 IEEE 802.16[즉, WiMAX(Worldwide Interoperability for Microwave Access)], CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, IS-2000(Interim Standard 2000), IS-95(Interim Standard 95), IS-856(Interim Standard 856), GSM(Global System for Mobile communications), EDGE(Enhanced Data rates for GSM Evolution), GSM EDGE(GERAN) 등과 같은 무선 기술을 구현할 수 있다.
도 48a의 기지국(114b)은, 예를 들어, 무선 라우터, 홈 노드 B, 홈 eNode B, 또는 액세스 포인트일 수 있고, 사업장, 가정, 차량, 캠퍼스 등과 같은 국소화된 지역에서의 무선 연결을 용이하게 해주는 임의의 적당한 RAT를 이용할 수 있다. 일 실시예에서, 기지국(114b) 및 WTRU(102c, 102d)는 WLAN(wireless local area network, 무선 근거리 통신망)을 설정하기 위해 IEEE 802.11과 같은 무선 기술을 구현할 수 있다. 다른 실시예에서, 기지국(114b) 및 WTRU(102c, 102d)는 WPAN(wireless personal area network, 무선 개인 영역 네트워크)을 설정하기 위해 IEEE 802.15와 같은 무선 기술을 구현할 수 있다. 또 다른 실시예에서, 기지국(114b) 및 WTRU(102c, 102d)는 피코셀(picocell) 또는 펨토셀(femtocell)을 설정하기 위해 셀룰러-기반 RAT(예컨대, WCDMA, CDMA2000, GSM, LTE, LTE-A 등)를 이용할 수 있다. 도 48a에 도시된 바와 같이, 기지국(114b)은 인터넷(110)에의 직접 연결을 가질 수 있다. 따라서, 기지국(114b)은 코어 네트워크(106)를 통해 인터넷(110)에 액세스할 필요가 없을 수 있다.
RAN(104)은 음성, 데이터, 응용 프로그램, 및 VoIP(voice over internet protocol) 서비스를 WTRU(102a, 102b, 102c, 102d) 중 하나 이상의 WTRU에 제공하도록 구성되어 있는 임의의 유형의 네트워크일 수 있는 코어 네트워크(106)와 통신하고 있을 수 있다. 예를 들어, 코어 네트워크(106)는 호출 제어, 대금 청구 서비스, 모바일 위치-기반 서비스, 선불 전화(pre-paid calling), 인터넷 연결, 비디오 배포 등을 제공하고 및/또는 사용자 인증과 같은 고수준 보안 기능을 수행할 수 있다. 도 48a에 도시되어 있지는 않지만, RAN(104) 및/또는 코어 네트워크(106)가 RAN(104)과 동일한 RAT 또는 상이한 RAT를 이용하는 다른 RAN과 직접 또는 간접 통신을 하고 있을 수 있다는 것을 잘 알 것이다. 예를 들어, E-UTRA 무선 기술을 이용하고 있을 수 있는 RAN(104)에 연결되는 것에 부가하여, 코어 네트워크(106)는 또한 GSM 무선 기술을 이용하는 다른 RAN(도시 생략)과 통신하고 있을 수 있다.
코어 네트워크(106)는 또한 WTRU(102a, 102b, 102c, 102d)가 PSTN(108), 인터넷(110) 및/또는 기타 네트워크(112)에 액세스하기 위한 게이트웨이로서 역할할 수 있다. PSTN(108)은 POTS(plain old telephone service)를 제공하는 회선-교환 전화 네트워크를 포함할 수 있다. 인터넷(110)은 TCP/IP 인터넷 프로토콜군 내의 TCP(transmission control protocol, 전송 제어 프로토콜), UDP(user datagram protocol, 사용자 데이터그램 프로토콜) 및 IP(internet protocol, 인터넷 프로토콜)와 같은 공통의 통신 프로토콜을 사용하는 상호연결된 컴퓨터 네트워크 및 장치의 전세계 시스템을 포함할 수 있다. 네트워크(112)는 다른 서비스 공급자가 소유하고 및/또는 운영하는 유선 또는 무선 통신 네트워크를 포함할 수 있다. 예를 들어, 네트워크(112)는 RAN(104)과 동일한 RAT 또는 상이한 RAT를 이용할 수 있는 하나 이상의 RAN에 연결된 다른 코어 네트워크를 포함할 수 있다.
통신 시스템(100) 내의 WTRU(102a, 102b, 102c, 102d) 중 일부 또는 전부는 다중-모드 기능을 포함할 수 있다 - 즉, WTRU(102a, 102b, 102c, 102d)가 상이한 무선 링크를 통해 상이한 무선 네트워크와 통신하기 위한 다수의 송수신기를 포함할 수 있다 -. 예를 들어, 도 48a에 도시된 WTRU(102c)는 셀룰러-기반 무선 기술을 이용할 수 있는 기지국(114a)과 통신하도록, 그리고 IEEE 802 무선 기술을 이용할 수 있는 기지국(114b)과 통신하도록 구성될 수 있다.
도 48b는 예시적인 WTRU(102)의 시스템도이다. 도 48b에 도시된 바와 같이, WTRU(102)는 프로세서(118), 송수신기(120), 송신/수신 요소(122), 스피커/마이크(124), 키패드(126), 디스플레이/터치패드(128), 비이동식 메모리(130), 이동식 메모리(132), 전원 공급 장치(134), GPS(global positioning system) 칩셋(136), 및 기타 주변 장치(138)를 포함할 수 있다. 실시예와 부합한 채로 있으면서 WTRU(102)가 상기한 요소들의 임의의 서브컴비네이션을 포함할 수 있다는 것을 잘 알 것이다.
프로세서(118)가 범용 프로세서, 전용 프로세서, 종래의 프로세서, DSP(digital signal processor), 복수의 마이크로프로세서, DSP 코어와 연관된 하나 이상의 마이크로프로세서, 제어기, 마이크로제어기, ASIC(Application Specific Integrated Circuit), FPGA(Field Programmable Gate Array) 회로, 임의의 다른 유형의 IC(integrated circuit), 상태 기계 등일 수 있다. 프로세서(118)는 WTRU(102)가 무선 환경에서 동작할 수 있게 해주는 신호 코딩, 데이터 처리, 전력 제어, 입력/출력 처리, 및/또는 임의의 다른 기능을 수행할 수 있다. 프로세서(118)는 송신/수신 요소(122)에 결합되어 있을 수 있는 송수신기(120)에 결합될 수 있다. 도 48b가 프로세서(118) 및 송수신기(120)를 개별 구성요소로서 나타내고 있지만, 프로세서(118) 및 송수신기(120)가 전자 패키지 또는 칩에 함께 통합되어 있을 수 있다는 것을 잘 알 것이다.
송신/수신 요소(122)는 공중 인터페이스(116)를 통해 기지국[예컨대, 기지국(114a)]으로 신호를 전송하거나 기지국으로부터 신호를 수신하도록 구성될 수 있다. 예를 들어, 일 실시예에서, 송신/수신 요소(122)는 RF 신호를 전송 및/또는 수신하도록 구성된 안테나일 수 있다. 다른 실시예에서, 송신/수신 요소(122)는, 예를 들어, IR, UV 또는 가시광 신호를 전송 및/또는 수신하도록 구성되어 있는 방출기/검출기일 수 있다. 또 다른 실시예에서, 송신/수신 요소(122)는 RF 신호 및 광 신호 둘 다를 전송 및 수신하도록 구성될 수 있다. 송신/수신 요소(122)가 무선 신호의 임의의 조합을 전송 및/또는 수신하도록 구성될 수 있다는 것을 잘 알 것이다.
그에 부가하여, 송신/수신 요소(122)가 도 48b에 단일 요소로서 나타내어져 있지만, WTRU(102)는 임의의 수의 송신/수신 요소(122)를 포함할 수 있다. 보다 구체적으로는, WTRU(102)는 MIMO 기술을 이용할 수 있다. 따라서, 일 실시예에서, WTRU(102)는 공중 인터페이스(116)를 통해 무선 신호를 전송 및 수신하기 위한 2개 이상의 송신/수신 요소(122)(예컨대, 다수의 안테나)를 포함할 수 있다.
송수신기(120)는 송신/수신 요소(122)에 의해 전송되어야 하는 신호를 변조하고 송신/수신 요소(122)에 의해 수신되는 신호를 복조하도록 구성될 수 있다. 앞서 살펴본 바와 같이, WTRU(102)는 다중-모드 기능을 가질 수 있다. 따라서, 송수신기(120)는 WTRU(102)가, 예를 들어, UTRA 및 IEEE 802.11과 같은 다수의 RAT를 통해 통신할 수 있게 해주는 다수의 송수신기를 포함할 수 있다.
WTRU(102)의 프로세서(118)는 스피커/마이크(124), 키패드(126), 및/또는 디스플레이/터치패드(128)[예컨대, LCD(liquid crystal display, 액정 디스플레이) 디스플레이 유닛 또는 OLED(organic light-emitting diode, 유기 발광 다이오드) 디스플레이 유닛]에 결합될 수 있고 그로부터 사용자 입력 데이터를 수신할 수 있다. 프로세서(118)는 또한 사용자 데이터를 스피커/마이크(124), 키패드(126) 및/또는 디스플레이/터치패드(128)로 출력할 수 있다. 그에 부가하여, 프로세서(118)는 비이동식 메모리(130) 및/또는 이동식 메모리(132)와 같은 임의의 유형의 적당한 메모리로부터의 정보에 액세스하고 그 메모리에 데이터를 저장할 수 있다. 비이동식 메모리(130)는 랜덤 액세스 메모리(RAM), 판독 전용 메모리(ROM), 하드 디스크, 또는 임의의 다른 유형의 메모리 저장 장치를 포함할 수 있다. 이동식 메모리(132)는 SIM(subscriber identity module, 가입자 식별 모듈) 카드, 메모리 스틱, SD(secure digital) 메모리 카드 등을 포함할 수 있다. 다른 실시예에서, 프로세서(118)는 WTRU(102) 상에 물리적으로 위치하지 않은[예컨대, 서버 또는 가정용 컴퓨터(도시 생략) 상의] 메모리로부터의 정보에 액세스하고 그 메모리에 데이터를 저장할 수 있다.
프로세서(118)는 전원 공급 장치(134)로부터 전력을 받을 수 있고, WTRU(102) 내의 다른 구성요소로 전력을 분배하고 및/또는 전력을 제어하도록 구성될 수 있다. 전원 공급 장치(134)는 WTRU(102)에 전원을 제공하는 임의의 적당한 장치일 수 있다. 예를 들어, 전원 공급 장치(134)는 하나 이상의 건전지[예컨대, 니켈-카드뮴(NiCd), 니켈-아연(NiZn), 니켈 수소화금속(NiMH), 리튬-이온(Li-ion) 등], 태양 전지, 연료 전지 등을 포함할 수 있다.
프로세서(118)는 또한 WTRU(102)의 현재 위치에 관한 위치 정보(예컨대, 경도 및 위도)를 제공하도록 구성될 수 있는 GPS 칩셋(136)에 결합될 수 있다. GPS 칩셋(136)으로부터의 정보에 부가하여 또는 그 대신에, WTRU(102)는 기지국[예컨대, 기지국(114a, 114b)] 공중 인터페이스(116)를 통해 위치 정보를 수신하고 및/또는 2개 이상의 근방의 기지국으로부터 수신되는 신호의 타이밍에 기초하여 그의 위치를 결정할 수 있다. 실시예와 부합한 채로 있으면서 WTRU(102)가 임의의 적당한 위치 결정 방법에 의해 위치 정보를 획득할 수 있다는 것을 잘 알 것이다.
프로세서(118)는 또한 부가의 특징, 기능 및/또는 유선 또는 무선 연결을 제공하는 하나 이상의 소프트웨어 및/또는 하드웨어 모듈을 포함할 수 있는 다른 주변 장치(138)에 결합될 수 있다. 예를 들어, 주변 장치(138)는 가속도계, 전자 나침반, 위성 송수신기, 디지털 카메라(사진 또는 비디오용), USB(universal serial bus) 포트, 진동 장치, 텔레비전 송수신기, 핸즈프리 헤드셋, 블루투스® 모듈, FM(frequency modulated, 주파수 변조) 라디오 유닛, 디지털 음악 플레이어, 미디어 플레이어, 비디오 게임 플레이어 모듈, 인터넷 브라우저 등을 포함할 수 있다.
도 48c는 일 실시예에 따른, RAN(104) 및 코어 네트워크(106)의 시스템도이다. 앞서 살펴본 바와 같이, RAN(104)은 공중 인터페이스(116)를 통해 WTRU(102a, 102b, 102c)와 통신하기 위해 UTRA 무선 기술을 이용할 수 있다. RAN(104)은 또한 코어 네트워크(106)와 통신하고 있을 수 있다. 도 48c에 도시된 바와 같이, RAN(104)은 각각이 공중 인터페이스(116)를 통해 WTRU(102a, 102b, 102c)와 통신하기 위한 하나 이상의 송수신기를 포함할 수 있는 노드-B(140a, 140b, 140c)를 포함할 수 있다. 노드-B(140a, 140b, 140c) 각각은 RAN(104) 내의 특정의 셀(도시 생략)과 연관되어 있을 수 있다. RAN(104)은 또한 RNC(142a, 142b)도 포함할 수 있다. 실시예와 부합한 채로 있으면서 RAN(104)이 임의의 수의 노드-B 및 RNC를 포함할 수 있다는 것을 잘 알 것이다.
도 48c에 도시된 바와 같이, 노드-B(140a, 140b)는 RNC(142a)와 통신하고 있을 수 있다. 그에 부가하여, 노드-B(140c)는 RNC(142b)와 통신하고 있을 수 있다. 노드-B(140a, 140b, 140c)는 Iub 인터페이스를 통해 각자의 RNC(142a, 142b)와 통신할 수 있다. RNC(142a, 142b)는 Iur 인터페이스를 통해 서로 통신하고 있을 수 있다. 각각의 RNC(142a, 142b)는 RNC가 연결되어 있는 각자의 노드-B(140a, 140b, 140c)를 제어하도록 구성되어 있을 수 있다. 그에 부가하여, 각각의 RNC(142a, 142b)는 외측 루프 전력 제어, 부하 제어, 허가 제어, 패킷 스케줄링, 핸드오버 제어, 매크로다이버시티(macrodiversity), 보안 기능, 데이터 암호화 등과 같은 다른 기능을 수행하거나 지원하도록 구성되어 있을 수 있다.
도 48c에 도시된 코어 네트워크(106)는 MGW(media gateway, 미디어 게이트웨이)(144), MSC(mobile switching center, 이동 교환국)(146), SGSN(serving GPRS support node, 서비스 제공 GPRS 지원 노드)(148), 및/또는 GGSN(gateway GPRS support node, 게이트웨이 GPRS 지원 노드)(150)을 포함할 수 있다. 상기 요소들 각각이 코어 네트워크(106)의 일부로서 나타내어져 있지만, 이들 요소 중 임의의 것이 코어 네트워크 운영자 이외의 엔터티에 의해 소유되고 및/또는 운영될 수 있다는 것을 잘 알 것이다.
RAN(104) 내의 RNC(142a)는 IuCS 인터페이스를 통해 코어 네트워크(106) 내의 MSC(146)에 연결될 수 있다. MSC(146)는 MGW(144)에 연결될 수 있다. MSC(146) 및 MGW(144)는, WTRU(102a, 102b, 102c)와 종래의 지상선(land-line) 통신 장치 사이의 통신을 용이하게 해주기 위해, PSTN(108)과 같은 회선 교환 네트워크에의 액세스를 WTRU(102a, 102b, 102c)에 제공할 수 있다.
RAN(104) 내의 RNC(142a)는 또한 IuPS 인터페이스를 통해 코어 네트워크(106) 내의 SGSN(148)에 연결될 수 있다. SGSN(148)은 GGSN(150)에 연결될 수 있다. SGSN(148) 및 GGSN(150)은, WTRU(102a, 102b, 102c)와 IP-기반 장치 사이의 통신을 용이하게 해주기 위해, 인터넷(110)과 같은 패킷 교환 네트워크에의 액세스를 WTRU(102a, 102b, 102c)에 제공할 수 있다.
앞서 살펴본 바와 같이, 코어 네트워크(106)는 또한 다른 서비스 공급자에 의해 소유되고 및/또는 운영되는 다른 유선 또는 무선 네트워크를 포함할 수 있는 네트워크(112)에 연결될 수 있다.
도 48d는 일 실시예에 따른, RAN(104) 및 코어 네트워크(106)의 시스템도이다. 앞서 살펴본 바와 같이, RAN(104)은 공중 인터페이스(116)를 통해 WTRU(102a, 102b, 102c)와 통신하기 위해 E-UTRA 무선 기술을 이용할 수 있다. RAN(104)은 또한 코어 네트워크(106)와 통신하고 있을 수 있다.
RAN(104)은 eNode B(140a, 140b, 140c)를 포함할 수 있지만, 실시예와 부합한 채로 있으면서 RAN(104)이 임의의 수의 eNode B를 포함할 수 있다는 것을 잘 알 것이다. eNode B(140a, 140b, 140c) 각각은 공중 인터페이스(116)를 통해 WTRU(102a, 102b, 102c)와 통신하기 위한 하나 이상의 송수신기를 포함할 수 있다. 일 실시예에서, eNode B(140a, 140b, 140c)는 MIMO 기술을 구현할 수 있다. 따라서, 예를 들어, eNode B(140a)는 WTRU(102a)로 무선 신호를 전송하고 그로부터 무선 신호를 수신하기 위해 다수의 안테나를 사용할 수 있다.
eNode B(140a, 140b, 140c) 각각은 특정의 셀(도시 생략)과 연관되어 있을 수 있고, 무선 자원 관리 결정, 핸드오버 결정, 상향링크 및/또는 하향링크에서의 사용자의 스케줄링 등을 처리하도록 구성되어 있을 수 있다. 도 48d에 도시된 바와 같이, eNode B(140a, 140b, 140c)는 X2 인터페이스를 통해 서로 통신할 수 있다.
도 48d에 도시된 코어 네트워크(106)는 MME(mobility management gateway, 이동성 관리 게이트웨이)(142), SGW(serving gateway, 서비스 제공 게이트웨이)(144), 및 PDN(packet data network, 패킷 데이터 네트워크) 게이트웨이(146)를 포함할 수 있다. 상기 요소들 각각이 코어 네트워크(106)의 일부로서 나타내어져 있지만, 이들 요소 중 임의의 것이 코어 네트워크 운영자 이외의 엔터티에 의해 소유되고 및/또는 운영될 수 있다는 것을 잘 알 것이다.
MME(142)는 S1 인터페이스를 통해 RAN(104) 내의 eNodeB(140a, 140b, 140c) 각각에 연결되어 있을 수 있고, 제어 노드로서 역할할 수 있다. 예를 들어, MME(142)는 WTRU(102a, 102b, 102c)의 사용자를 인증하는 것, 베어러 활성화/비활성화, WTRU(102a, 102b, 102c)의 초기 접속(initial attach) 동안 특정의 SGW(serving gateway)를 선택하는 것 등을 책임지고 있을 수 있다. MME(142)는 또한 RAN(104)과 GSM 또는 WCDMA와 같은 다른 무선 기술을 이용하는다른 RAN(도시 생략) 간에 전환하는 제어 평면 기능(control plane function)을 제공할 수 있다.
SGW(serving gateway)(144)는 S1 인터페이스를 통해 RAN(104) 내의 eNode B(140a, 140b, 140c) 각각에 연결될 수 있다. 서비스 제공 게이트웨이(144)는 일반적으로 WTRU(102a, 102b, 102c)로/로부터 사용자 데이터 패킷을 라우팅하고 전달할 수 있다. SGW(serving gateway)(144)는 eNode B간 핸드오버 동안 사용자 평면을 앵커링(anchoring)하는 것, WTRU(102a, 102b, 102c)에 대해 하향링크 데이터가 이용가능할 때 페이징(paging)을 트리거하는 것, WTRU(102a, 102b, 102c)의 컨텍스트를 관리하고 저장하는 것 등과 같은 다른 기능도 수행할 수 있다.
SGW(serving gateway)(144)는, WTRU(102a, 102b, 102c)와 IP-기반(IP-enabled) 장치 사이의 통신을 용이하게 해주기 위해, 인터넷(110)과 같은 패킷 교환 네트워크에의 액세스를 WTRU(102a, 102b, 102c)에 제공할 수 있는 PDN 게이트웨이(146)에도 연결될 수 있다.
코어 네트워크(106)는 기타 네트워크와의 통신을 용이하게 해줄 수 있다. 예를 들어, 코어 네트워크(106)는, WTRU(102a, 102b, 102c)와 종래의 지상선(land-line) 통신 장치 사이의 통신을 용이하게 해주기 위해, PSTN(108)과 같은 회선 교환 네트워크에의 액세스를 WTRU(102a, 102b, 102c)에 제공할 수 있다. 예를 들어, 코어 네트워크(106)는 코어 네트워크(106)와 PSTN(108) 사이의 인터페이스로서 역할하는 IP 게이트웨이[예컨대, IMS(IP multimedia subsystem, IP 멀티미디어 서브시스템) 서버]를 포함할 수 있거나 그와 통신할 수 있다. 그에 부가하여, 코어 네트워크(106)는 다른 서비스 공급자에 의해 소유되고 및/또는 운영되는 다른 유선 또는 무선 네트워크를 포함할 수 있는 네트워크(112)에의 액세스를 WTRU(102a, 102b, 102c)에 제공할 수 있다.
도 48e는 일 실시예에 따른, RAN(104) 및 코어 네트워크(106)의 시스템도이다. RAN(104)은 공중 인터페이스(116)를 통해 WTRU(102a, 102b, 102c)와 통신하기 위해 IEEE 802.16 무선 기술을 이용하는 ASN(access service network)일 수 있다. 이하에서 더 논의할 것인 바와 같이, WTRU(102a, 102b, 102c)의 상이한 기능적 엔터티 간의 통신 링크, RAN(104), 및 코어 네트워크(106)가 기준점으로서 정의될 수 있다.
도 48e에 도시된 바와 같이, RAN(104)은 기지국(140a, 140b, 140c) 및 ASN 게이트웨이(142)를 포함할 수 있지만, RAN(104)이 실시예와 부합한 채로 있으면서 임의의 수의 기지국 및 ASN 게이트웨이를 포함할 수 있다는 것을 잘 알 것이다. 기지국(140a, 140b, 140c)은 각각이 RAN(104) 내의 특정의 셀(도시 생략)과 연관될 수 있고, 각각이 공중 인터페이스(116)를 통해 WTRU(102a, 102b, 102c)와 통신하기 위한 하나 이상의 송수신기를 포함할 수 있다. 일 실시예에서, 기지국(140a, 140b, 140c)은 MIMO 기술을 구현할 수 있다. 따라서, 예를 들어, 기지국(140a)은 WTRU(102a)로 무선 신호를 전송하고 그로부터 무선 신호를 수신하기 위해 다수의 안테나를 사용할 수 있다. 기지국(140a, 140b, 140c)은 또한 핸드오프 트리거링, 터널 설정, 무선 자원 관리, 트래픽 분류, QoS(quality of service) 정책 시행 등과 같은 이동성 관리 기능을 제공할 수 있다. ASN 게이트웨이(142)는 트래픽 집계 지점으로서 역할할 수 있고, 페이징, 가입자 프로필의 캐싱, 코어 네트워크(106)로의 라우팅 등을 책임지고 있을 수 있다.
WTRU(102a, 102b, 102c)와 RAN(104) 사이의 공중 인터페이스(116)는 IEEE 802.16 규격을 구현하는 R1 기준점으로서 정의될 수 있다. 그에 부가하여, WTRU(102a, 102b, 102c) 각각은 코어 네트워크(106)와 논리 인터페이스(도시 생략)를 설정할 수 있다. WTRU(102a, 102b, 102c)와 코어 네트워크(106) 사이의 논리 인터페이스는 인증, 허가, IP 호스트 구성 관리, 및/또는 이동성 관리를 위해 사용될 수 있는 R2 기준점으로서 정의될 수 있다.
기지국(140a, 140b, 140c) 각각 사이의 통신 링크는 기지국들 사이의 WTRU 핸드오버 및 데이터 전송을 용이하게 해주는 프로토콜을 포함하는 R8 기준점으로서 정의될 수 있다. 기지국(140a, 140b, 140c)과 ASN 게이트웨이(215) 사이의 통신 링크는 R6 기준점으로서 정의될 수 있다. R6 기준점은 WTRU(102a, 102b, 102c) 각각과 연관된 이동성 이벤트에 기초하여 이동성 관리를 용이하게 해주는 프로토콜을 포함할 수 있다.
도 48e에 도시된 바와 같이, RAN(104)은 코어 네트워크(106)에 연결될 수 있다. RAN(104)과 코어 네트워크(106) 사이의 통신 링크는, 예를 들어, 데이터 전송 및 이동성 관리 기능을 용이하게 해주는 프로토콜을 포함하는 R3 기준점으로서 정의될 수 있다. 코어 네트워크(106)는 MIP-HA(mobile IP home agent, 이동 IP 홈 에이전트), AAA(authentication, authorization, accounting) 서버(146), 및 게이트웨이(148)를 포함할 수 있다. 상기 요소들 각각이 코어 네트워크(106)의 일부로서 나타내어져 있지만, 이들 요소 중 임의의 것이 코어 네트워크 운영자 이외의 엔터티에 의해 소유되고 및/또는 운영될 수 있다는 것을 잘 알 것이다.
MIP-HA는 IP 주소 관리를 책임지고 있을 수 있고, WTRU(102a, 102b, 102c)가 상이한 ASN 및/또는 상이한 코어 네트워크 사이에서 로밍할 수 있게 해줄 수 있다. MIP-HA(144)는, WTRU(102a, 102b, 102c)와 IP-기반 장치 사이의 통신을 용이하게 해주기 위해, 인터넷(110)과 같은 패킷 교환 네트워크에의 액세스를 WTRU(102a, 102b, 102c)에 제공할 수 있다. AAA 서버(146)는 사용자 인증 및 사용자 서비스를 지원하는 것을 책임지고 있을 수 있다. 게이트웨이(148)는 다른 네트워크와의 연동을 용이하게 해줄 수 있다. 예를 들어, 게이트웨이(148)는, WTRU(102a, 102b, 102c)와 종래의 지상선(land-line) 통신 장치 사이의 통신을 용이하게 해주기 위해, PSTN(108)과 같은 회선 교환 네트워크에의 액세스를 WTRU(102a, 102b, 102c)에 제공할 수 있다. 그에 부가하여, 게이트웨이(148)는 다른 서비스 공급자에 의해 소유되고 및/또는 운영되는 다른 유선 또는 무선 네트워크를 포함할 수 있는 네트워크(112)에의 액세스를 WTRU(102a, 102b, 102c)에 제공할 수 있다.
도 48e에 도시되어 있지는 않지만, RAN(104)이 다른 ASN에 연결될 수 있다는 것과 코어 네트워크(106)가 다른 코어 네트워크에 연결될 수 있다는 것을 잘 알 것이다. RAN(104)과 다른 ASN 사이의 통신 링크가 RAN(104)과 다른 ASN 사이의 WTRU(102a, 102b, 102c)의 이동성을 조정하는 프로토콜을 포함할 수 있는 R4 기준점으로서 정의될 수 있다. 코어 네트워크(106)와 다른 코어 네트워크 사이의 통신 링크가 홈 코어 네트워크와 방문한 코어 네트워크 사이의 연동을 용이하게 해주는 프로토콜을 포함할 수 있는 R5 기준으로서 정의될 수 있다.
특징 및 요소가 특정의 조합으로 앞서 기술되어 있지만, 당업자라면 각각의 특징 또는 요소가 단독으로 또는 다른 특징 및 요소와 임의의 조합으로 사용될 수 있다는 것을 잘 알 것이다. 그에 부가하여, 본 명세서에 기술된 방법이 컴퓨터 또는 프로세서에서 실행하기 위해 컴퓨터 판독가능 매체에 포함되어 있는 컴퓨터 프로그램, 소프트웨어, 또는 펌웨어로 구현될 수 있다. 컴퓨터 판독가능 매체의 일례는 전자 신호(유선 또는 무선 연결을 통해 전송됨) 및 컴퓨터 판독가능 저장 매체를 포함한다. 컴퓨터 판독가능 저장 매체의 일례로는 ROM(read only memory), RAM(random access memory), 레지스터, 캐시 메모리, 반도체 메모리 장치, 내장형 하드 디스크 및 이동식 디스크 등의 자기 매체, 광자기 매체, 그리고 CD-ROM 디스크 및 DVD(digital versatile disk) 등의 광 매체가 있지만, 이들로 제한되지 않는다. 소프트웨어와 연관된 프로세서는 WTRU, UE, 단말, 기지국, RNC, 또는 임의의 호스트 컴퓨터에서 사용하기 위한 무선 주파수 송수신기를 구현하는 데 사용될 수 있다.
결론
ETSI TS 102 690 VO.12.3 (2011-06)의 초안 및 그의 이전 버전들(모두 합하여, "Draft ETSI Standards for M2M Communications(M2M 통신을 위한 ETSI 표준 초안)"라고 함)은 M2M 통신을 위한 ETSI 표준 초안과 관련하여 이러한 용어의 의미를 정의하는 주어진 정의를 가지는 다수의 용어를 포함하고 있다. ETSI TS 102 690 VO.12.3 (2011-06) 초안 및 그의 이전 버전들에 의해 명시되고, 개시되며 및/또는 참조되는 용어 및 관련 정의가 참조 문헌으로서 본 명세서에 포함된다.
실시예
일 실시예에서, 방법은 M2M 환경에서 M2M 엔터티를 관리하는 하나 이상의 관리 계층을 구현하는 단계를 포함할 수 있다. 이 방법은 또한 복수의 관리 계층을 사용하여 M2M 영역 네트워크(M2M area network)를 관리하는 단계를 포함할 수 있고, 여기서 M2M 영역 네트워크는 하나 이상의 M2M 종단 디바이스(M2M end device)를 포함할 수 있다. M2M 종단 디바이스는, 예를 들어, M2M 게이트웨이 및/또는 M2M 디바이스를 포함할 수 있다. 관리 계층은 응용 프로그램 관리 계층, 서비스 관리 계층, 네트워크 관리 계층 및 디바이스 관리 계층 중 임의의 것을 포함할 수 있다. 관리 계층은 M2M 엔터티의 구성 관리, 장애 관리, 및 성능 관리 중 임의의 것을 제공할 수 있다.
일 실시예에서, 방법은 원격 엔터티 관리(remote entity management, "REM")를 위한 서비스 능력(service capability, "SC")으로 그리고 복수의 관리 계층들 중 하나에 따라 제2 M2M 엔터티의 REM을 수행하는 하위 리소스 구조체(subordinate resource structure)를 가지는 리소스 구조체로 제1 M2M 엔터티를 구성하는 단계를 포함할 수 있다. 이 방법은 하위 리소스 구조체의 리소스 및 속성 중 임의의 것을 조작함으로써 제2 M2M 엔터티의 REM을 수행하는 단계를 추가로 포함할 수 있다.
선행 실시예에서와 같은 방법으로서, 제1 M2M 엔터티가 M2M 서버일 수 있고, 제2 M2M 엔터티가 M2M 응용 프로그램, M2M 서비스 능력, M2M 영역 네트워크, M2M 게이트웨이 또는 M2M 디바이스일 수 있는 것인 방법.
선행 실시예들 중 적어도 하나의 실시예에서와 같은 방법으로서, 복수의 관리 계층들이 디바이스 관리 계층, 네트워크 관리 계층, 서비스 관리 계층 및 응용 프로그램 관리 계층 중 적어도 2개를 포함할 수 있는 것인 방법.
선행 실시예들 중 적어도 하나의 실시예에서와 같은 방법으로서, 제2 M2M 엔터티의 원격 엔터티 관리에 대한 하위 리소스 구조체가 응용 프로그램 관리 계층에 따른 M2M 응용 프로그램의 원격 엔터티 관리를 위한 리소스 구조체를 포함할 수 있는 것인 방법.
선행 실시예에서와 같은 방법으로서, 응용 프로그램 관리 계층이 응용 프로그램 라이프 사이클 관리를 수행하는 하나 이상의 기능을 포함할 수 있는 것인 방법.
선행 실시예들 중 적어도 하나의 실시예에서와 같은 방법으로서, 제2 M2M 엔터티의 원격 엔터티 관리에 대한 하위 리소스 구조체가 서비스 관리 계층에 따른 M2M 서비스 능력의 원격 엔터티 관리를 위한 리소스 구조체를 포함할 수 있는 것인 방법.
선행 실시예에서와 같은 방법으로서, 서비스 관리가 소프트웨어 관리 및/또는 펌웨어 관리를 수행하는 기능을 포함하는 것인 방법.
선행 실시예들 중 적어도 하나의 실시예에서와 같은 방법으로서, 제2 M2M 엔터티의 원격 엔터티 관리에 대한 하위 리소스 구조체가 네트워크 관리 계층에 따른 M2M 영역 네트워크의 원격 엔터티 관리를 위한 리소스 구조체를 포함할 수 있는 것인 방법.
선행 실시예들 중 적어도 하나의 실시예에서와 같은 방법으로서, 제2 M2M 엔터티의 원격 엔터티 관리에 대한 하위 리소스 구조체가 디바이스 관리 계층에 따른 M2M 디바이스의 원격 엔터티 관리를 위한 리소스 구조체를 포함할 수 있는 것인 방법.
선행 실시예들 중 적어도 하나의 실시예에서와 같은 방법으로서, 복수의 관리 계층들 각각이 제2 M2M 엔터티의 구성 관리, 장애 관리, 및 성능 관리 중 임의의 것을 수행하는 하나 이상의 기능을 정의할 수 있는 것인 방법.
선행 실시예들 중 적어도 하나의 실시예에서와 같은 방법으로서, 하위 리소스 구조체의 리소스 및 속성 중 임의의 것을 조작하라는 명령을, 제1 M2M 엔터티에서, 수신하는 단계를 추가로 포함할 수 있고, 제2 M2M 엔터티의 REM이 명령에 응답하여 수행될 수 있는 것인 방법.
선행 실시예에서와 같은 방법으로서, 명령이 RESTful 메소드를 포함하는 것인 방법.
선행 실시예들 중 적어도 하나의 실시예에서와 같은 방법으로서, 하위 리소스 구조체의 리소스 및 속성 중 임의의 것을 조작하라는 제1 명령을, 제1 M2M 엔터티에서, 수신하는 단계를 추가로 포함할 수 있는 것인 방법.
선행 실시예에서와 같은 방법으로서, 제2 M2M 엔터티의 REM을 수행하는 단계가 하위 리소스 구조체의 리소스 및 속성 중 임의의 것을 조작하라는 제2 명령을, 제2 M2M 엔터티에서, 수신하는 단계, 및 수신된 제2 명령에 응답하여 제2 M2M 엔터티의 REM을 수행하는 단계를 포함할 수 있는 것인 방법.
선행 실시예에서와 같은 방법으로서, 제1 및 제2 명령 둘 다가 RESTful 메소드(RESTful method)를 포함할 수 있는 것인 방법.
선행 실시예들 중 적어도 하나의 실시예에서와 같은 방법으로서, 제1 명령이 RESTful 메소드를 포함할 수 있고, 제2 명령이 비RESTful 메소드(non-RESTful method)를 포함하는 것인 방법.
선행 실시예들 중 적어도 하나의 실시예에서와 같은 방법으로서, 제2 M2M 엔터티의 REM을 수행하는 단계가 하위 리소스 구조체의 리소스 및 속성 중 임의의 것을 조작하라는 명령을, 제2 M2M 엔터티에서, 수신하는 단계, 및 수신된 명령에 응답하여 제2 M2M 엔터티의 REM을 수행하는 단계를 포함할 수 있는 것인 방법.
선행 실시예에서와 같은 방법으로서, 명령이 비RESTful 메소드 또는 RESTful 메소드 중 어느 하나일 수 있는 것인 방법.
선행 실시예들 중 적어도 하나의 실시예에서와 같은 방법으로서, 제2 M2M 엔터티가 하위 리소스 구조체의 사본을 포함할 수 있고, 제2 M2M 엔터티의 REM을 수행하는 단계가 하위 리소스 구조체의 리소스 및 속성 중 임의의 것을 조작한 후에 하위 리소스 구조체를 복제하기 위해 하위 리소스 구조체의 사본을 조작하는 단계를 포함하는 것인 방법.
일 실시예에서, 장치는 REM을 위한 SC로 그리고 복수의 관리 계층들 중 하나에 따라 제2 M2M 엔터티의 REM을 수행하는 하위 리소스 구조체를 가지는 리소스 구조체로 구성된 제1 M2M 엔터티를 포함할 수 있다. 이 장치는 하위 리소스 구조체의 리소스 및 속성 중 임의의 것을 조작함으로써 제2 M2M 엔터티의 REM을 수행하도록 구성되어 있는 프로세서를 추가로 포함할 수 있다.
선행 실시예에서와 같은 장치로서, 제1 M2M 엔터티가 M2M 서버를 포함할 수 있고, 제2 M2M 엔터티가 M2M 응용 프로그램, M2M 서비스 능력, M2M 영역 네트워크, M2M 게이트웨이 또는 M2M 디바이스를 포함할 수 있는 것인 장치.
선행 실시예들 중 적어도 하나의 실시예에서와 같은 장치로서, 복수의 관리 계층들이 디바이스 관리 계층, 네트워크 관리 계층, 서비스 관리 계층 및 응용 프로그램 관리 계층 중 2개 이상을 포함할 수 있는 것인 장치.
선행 실시예들 중 적어도 하나의 실시예에서와 같은 장치로서, 제2 M2M 엔터티의 REM에 대한 하위 리소스 구조체가 응용 프로그램 관리 계층에 따른 M2M 응용 프로그램의 REM을 위한 리소스 구조체를 포함할 수 있는 것인 장치.
선행 실시예들 중 적어도 하나의 실시예에서와 같은 장치로서, 응용 프로그램 관리 계층이 응용 프로그램 라이프 사이클 관리를 수행하는 기능을 포함할 수 있는 것인 장치.
선행 실시예들 중 적어도 하나의 실시예에서와 같은 장치로서, 제2 M2M 엔터티의 원격 엔터티 관리에 대한 하위 리소스 구조체가 서비스 관리 계층에 따른 M2M 서비스 능력의 원격 엔터티 관리를 위한 리소스 구조체를 포함할 수 있는 것인 장치.
선행 실시예에서와 같은 장치로서, 서비스 관리가 소프트웨어 관리 및/또는 펌웨어 관리를 수행하는 기능을 포함할 수 있는 것인 장치.
선행 실시예들 중 적어도 하나의 실시예에서와 같은 장치로서, 제2 M2M 엔터티의 원격 엔터티 관리에 대한 하위 리소스 구조체가 네트워크 관리 계층에 따른 M2M 영역 네트워크의 원격 엔터티 관리를 위한 리소스 구조체를 포함할 수 있는 것인 장치.
선행 실시예들 중 적어도 하나의 실시예에서와 같은 장치로서, 제2 M2M 엔터티의 원격 엔터티 관리에 대한 하위 리소스 구조체가 디바이스 관리 계층에 따른 M2M 디바이스의 원격 엔터티 관리를 위한 리소스 구조체를 포함할 수 있는 것인 장치.
선행 실시예들 중 적어도 하나의 실시예에서와 같은 장치로서, 복수의 관리 계층들 각각이 제2 M2M 엔터티의 구성 관리, 장애 관리, 및 성능 관리 중 임의의 것을 수행하는 기능을 정의할 수 있는 것인 장치.
선행 실시예들 중 적어도 하나의 실시예에서와 같은 장치로서, 제1 M2M 엔터티가 하위 리소스 구조체의 리소스 및 속성 중 임의의 것을 조작하라는 명령을 수신하는 SC를 포함할 수 있고, 제2 M2M 엔터티의 REM이 명령에 응답하여 수행될 수 있는 것인 장치.
선행 실시예들 중 적어도 하나의 실시예에서와 같은 장치로서, 명령이 RESTful 메소드일 수 있는 것인 장치.
선행 실시예들 중 적어도 하나의 실시예에서와 같은 장치로서, 제1 M2M 엔터티가 (i) 하위 리소스 구조체의 리소스 및 속성 중 임의의 것을 조작하라는 제1 명령을 수신하는 SC, 및 (ii) 리소스의 사본 및 제2 M2M 엔터티에 유지되는 하위 리소스 구조체의 사본의 속성의 사본 중 임의의 것을 조작하라는 제2 명령을 제2 M2M 엔터티로 전달하는 SC를 포함할 수 있는 것인 장치.
선행 실시예에서와 같은 장치로서, 프로세서가 제2 명령에 응답하여 리소스의 사본 및 제2 M2M 엔터티에 유지되는 하위 리소스 구조체의 사본의 속성의 사본 중 임의의 것을 조작하게 하는 제2 명령을 제2 M2M 엔터티로 송신하도록 구성되어 있을 수 있는 것인 장치.
선행 실시예들 중 적어도 하나의 실시예에서와 같은 장치로서, 제1 및 제2 명령 둘 다가 RESTful 메소드일 수 있거나, 다른 대안으로서, 상기 제1 명령이 RESTful 메소드일 수 있고 제2 명령이 비RESTful 메소드일 수 있는 것인 장치.
선행 실시예들 중 적어도 하나의 실시예에서와 같은 장치로서, 제1 M2M 엔터티가 (i) 리소스의 사본 및 제2 M2M 엔터티에 유지되는 하위 리소스 구조체의 사본의 속성의 사본 중 임의의 것을 조작하라는 명령을 제2 M2M 엔터티로 전달하는 SC를 포함할 수 있는 것인 장치.
선행 실시예에서와 같은 장치로서, 프로세서가 제2 명령에 응답하여 리소스의 사본 및 제2 M2M 엔터티에 유지되는 하위 리소스 구조체의 사본의 속성의 사본 중 임의의 것을 조작하게 하는 명령을 제2 M2M 엔터티로 송신하도록 구성되어 있을 수 있는 것인 장치.
선행 실시예에서와 같은 장치로서, 명령이 비RESTful 메소드 또는, 다른 대안으로서, RESTful 메소드일 수 있는 것인 장치.
일 실시예에서, 시스템은 REM을 위한 서비스 능력으로 그리고 복수의 관리 계층들 중 하나에 따라 제2 M2M 엔터티의 REM을 수행하는 하위 리소스 구조체를 가지는 리소스 구조체로 구성된 제1 M2M 엔터티를 가지는 서버를 포함할 수 있다. 이 시스템은 또한 하위 리소스 구조체의 리소스 및 속성 중 임의의 것을 조작함으로써 제2 M2M 엔터티의 REM을 수행하도록 구성되어 있는 프로세서를 포함할 수 있다. 이 시스템은 하위 리소스 구조체의 사본으로 구성된 제2 M2M 엔터티를 가지는 디바이스; 및 서버에 의한 조작 후에 하위 리소스 구조체를 복제하기 위해 하위 리소스 구조체의 사본을 조작하도록 구성되어 있는 프로세서를 추가로 포함할 수 있다.
일 실시예에서, 유형의(tangible) 컴퓨터 판독가능 저장 매체가 (i) REM을 위한 SC로 그리고 복수의 관리 계층들 중 하나에 따라 제2 M2M 엔터티의 REM을 수행하는 하위 리소스 구조체를 가지는 리소스 구조체로 제1 M2M 엔터티를 구성하고; (ii) 하위 리소스 구조체의 리소스 및 속성 중 임의의 것을 조작함으로써 제2 M2M 엔터티의 REM을 수행하는 실행가능 명령어를 저장할 수 있다. 실행가능 명령어는 컴퓨팅 디바이스의 메모리에 로드가능하고 그에 의해 실행가능할 수 있다.
일 실시예에서, 유형의(tangible) 컴퓨터 판독가능 저장 매체가 (i) REM을 위한 SC로 그리고 복수의 관리 계층들 중 하나에 따라 제2 M2M 엔터티의 REM을 수행하는 하위 리소스 구조체를 가지는 리소스 구조체로 제1 M2M 엔터티를 구성하고; (ii) 하위 리소스 구조체의 리소스 및 속성 중 임의의 것을 조작함으로써 제2 M2M 엔터티의 REM을 수행하며; (iii) 리소스 및 하위 리소스 구조체의 속성 중 임의의 것을 조작한 후에 하위 리소스 구조체를 복제하기 위해 제2 M2M 엔터티에 의해 유지되는 하위 리소스 구조체의 사본을 조작하는 실행가능 명령어를 저장할 수 있다.
일 실시예에서, 방법은 M2M 환경에서 관리 기능을 수행하기 위해 클라이언트/서버-기반 원격 엔터티 관리(xREM)를 구현하는 단계를 포함할 수 있다. 이 방법은 또한 M2M 환경에서 M2M 디바이스에 모델을 적용하는 단계를 포함할 수 있다.
일 실시예에서, 방법은 터널-기반 기법을 사용하여 다수의 관리 프로토콜을 사용하여 M2M 환경에서 xREM을 구현하는 단계; 및 M2M 환경에서 M2M 디바이스에 모델을 적용하는 단계를 포함할 수 있다.
일 실시예에서, 방법은 속성 컴포넌트(attribute component)를 포함하는 리소스 command를 제공하는 단계, 및 리소스 command를 M2M 종단 디바이스로 전달하는 단계를 포함할 수 있다.
선행 실시예에서와 같은 방법으로서, 리소스 command가 비RESTful 명령일 수 있는 것인 방법.
일 실시예에서, 방법은 속성 컴포넌트 및 어쩌면 어떤 서브파라미터를 가지는 리소스 commands 구조체를 제공하는 단계를 포함할 수 있다. 이 방법은 또한 리소스 command를 M2M 종단 디바이스로 전달하는 단계를 포함할 수 있다. 종래의 비RESTful 관리 명령이 RESTful 메소드를 사용하여 M2M 종단 디바이스 상에서 용이하게 동작될 수 있다.
일 실시예에서, 방법은 accessHistories 리소스 구조체를 M2M 디바이스 또는 M2M 게이트웨이에 저장하는 단계, M2M 디바이스 또는 M2M 게이트웨이에서 동작을 검출하는 단계, 및 동작과 연관되어 있는 적어도 하나의 상세를 기억하기 위해 accessHistories 리소스 구조체를 조작하는 단계를 포함할 수 있다.
일 실시예에서, 방법은 M2M(machine-to-machine) 디바이스 또는 게이트웨이에 대한 권한을 위임하라는 요청을 수신하는 단계, 및 M2M 디바이스 또는 게이트웨이에 대한 권한을 허가하는 단계를 포함할 수 있다.
일 실시예에서, 방법이 M2M 종단 디바이스에서 구현될 수 있다. 이 방법은 M2M 종단 디바이스를 관리하는 하나 이상의 속성 컴포넌트를 가지는 리소스 command를 수신하는 단계를 포함할 수 있다.
선행 실시예에서와 같은 방법으로서, 리소스 command에 기초하여 하나 이상의 관리 기능을 적용하는 단계를 추가로 포함할 수 있는 것인 방법.
일 실시예에서, 방법은 하나 이상의 속성 컴포넌트를 포함하는 리소스 command를 제공하는 단계, 및 리소스 command를 M2M 종단 디바이스로 전달하는 단계를 포함할 수 있다.
일 실시예에서, 제1 시스템에서 xREM을 수행하는 방법은 예를 들어, Draft ETSI TS 102 690 등의 M2M 통신을 위한 프로토콜("M2M 통신 프로토콜")에 따라 통신하도록 구성되어 있는 제1, 제2 및 제3 디바이스를 포함할 수 있다. M2M 통신 프로토콜은 각각의 논리 계층("관리 계층")에 존재하는 엔터티를 관리하는 논리 계층의 스택 또는 모음을 정의할 수 있다. 이들 관리 계층은, 예를 들어, M2M 응용 프로그램 관리 계층, M2M 서비스 능력 계층, M2M 네트워크 관리 계층 및 M2M 디바이스 관리 계층을 포함할 수 있다. 제1 디바이스는 관리 계층의 제1 논리 계층("제1 관리 계층")에 존재하는 엔터티를 정의할 수 있다. 엔터티는, 예를 들어, M2M 응용 프로그램, M2M 서비스 능력, M2M 영역 네트워크, M2M 게이트웨이 또는 M2M 디바이스일 수 있다. 제1 디바이스는 제1 관리 계층에 따라 엔터티를 관리하는 리소스("제1 관리 계층 리소스")를 정의하는 제1 데이터 구조체를 포함할 수 있다. 제2 디바이스는 제1 관리 계층 리소스도 역시 정의하는 제2 데이터 구조체를 포함할 수 있다. 제2 디바이스는 제1 및 제3 디바이스와 통신 연결될 수 있다.
이 방법은 제2 디바이스로부터 제3 디바이스로, 제1 관리 계층 리소스를 식별해주는 식별자를 제공하는 단계를 포함할 수 있다. 이 방법은 또한 제1 관리 계층 리소스에 적용하기 위한 식별자 및 정보를, 제3 디바이스로부터 제2 디바이스에서, 수신하는 단계, 및 정보를 제1 관리 계층 리소스에 적용하는 단계를 포함할 수 있다.
하나 이상의 경우에서, 정보를 제1 관리 계층 리소스에 적용하는 단계는 제2 데이터 구조체를 조작하는 단계를 포함할 수 있다. 다른 대안으로서, 정보를 제1 관리 계층 리소스에 적용하는 단계는 제1 디바이스로 하여금 제1 데이터 구조체를 조작하게 하기 위해 제2 디바이스로부터 제1 디바이스로 정보를 송신하는 단계를 포함할 수 있다.
식별자는 URI(uniform resource identifier), 링크 및 주소 중 임의의 것을 포함하고 및/또는 그것일 수 있다. 제1 관리 계층 리소스는 관리 객체를 포함하고 및/또는 정의할 수 있다. 게다가, 제1, 제2 및 제3 디바이스 각각은 M2M 통신 프로토콜에 따라 통신하는 모듈을 포함할 수 있다. 제3 디바이스는 제1 관리 계층 리소스에 적용하기 위한 정보를 제공하도록 구성되어 있는 응용 프로그램(예컨대, M2M 응용 프로그램)을 추가로 포함할 수 있고, 응용 프로그램의 실행은 M2M 통신 프로토콜에 따라 정보를 전달하는 것을 포함한다. 제1 디바이스는 또한 응용 프로그램을 포함할 수 있고, 이러한 응용 프로그램의 실행은 M2M 통신 프로토콜에 따라 정보를 전달하는 것을 포함한다.
하나 이상의 실시예에서, 제1 디바이스는 가전 제품일 수 있고, 제3 디바이스는 WTRU(wireless transmit/receive unit, 무선 송수신 유닛)일 수 있으며, 제2 디바이스는 서버를 포함할 수 있다.
다른 예로서, xREM에 대한 장치가 개시되어 있다. 이 장치는 M2M 통신 프로토콜에 따라 통신하도록 구성되어 있는 제1 디바이스를 포함한다. 상기와 같이, M2M 통신 프로토콜은 관리 계층의 스택 또는 모음을 정의한다. 제1 디바이스는 제1 데이터 구조체를 포함할 수 있다. 제1 데이터 구조체는, 제1 관리 계층에 따라, 제1 관리 계층에 존재하는 제2 디바이스의 엔터티를 관리하는 제1 관리 계층 리소스를 정의한다. 제1 디바이스는 또한 제2 디바이스 및 제3 디바이스와 통신 연결되어 있을 수 있다. 제1 디바이스는 제3 디바이스로, 제1 관리 계층 리소스를 식별해주는 식별자를 제공하고; 제1 관리 계층 리소스에 적용하기 위한 식별자 및 정보를, 제3 디바이스로부터, 수신하며; 정보를 제1 관리 계층 리소스에 적용하도록 구성되어 있는 실행가능 명령어를 저장하도록 구성되어 있는 메모리를 추가로 포함할 수 있다. 제1 디바이스는 또한 메모리로부터 실행가능 명령어를 획득하고 실행가능 명령어를 실행하도록 구성되어 있는 프로세서를 포함할 수 있다.
식별자는 URI(uniform resource identifier), 링크 및 주소 중 임의의 것을 포함하고 및/또는 그것일 수 있다. 제1 관리 계층 리소스는 관리 객체를 포함할 수 있다.
제1 디바이스는 M2M 통신 프로토콜에 따라 통신하는 모듈을 포함할 수 있다. 제1 관리 계층 리소스에 적용하기 위한 정보가 제3 디바이스의 응용 프로그램으로부터 수신될 수 있다. 제1 디바이스는 서버를 포함할 수 있고, 제2 디바이스는 가전 제품일 수 있으며, 제3 디바이스는 WTRU일 수 있다.
제2 시스템에서 xREM을 수행하는 방법의 다른 예가 개시되어 있다. 제2 시스템은 M2M 통신 프로토콜에 따라 통신하도록 구성되어 있는 제1 및 제2 디바이스를 포함할 수 있다. M2M 통신 프로토콜은 관리 계층을 정의한다. 제1 디바이스는 제1 관리 계층에 존재하는 엔터티를 정의하고, 제1 관리 계층 리소스를 정의하는 제1 데이터 구조체를 포함한다. 제2 디바이스는 제1 관리 계층 리소스도 역시 정의하는 제2 데이터 구조체를 포함하고 있다. 제1 디바이스는 제2 디바이스와 통신 연결되어 있을 수 있다.
이 방법은 제1 디바이스가 제1 관리 계층에 따라 엔터티를 관리하는 관리 프로토콜의 유형을 정의하기 위해 제2 디바이스와 협상하는 단계를 포함할 수 있다. 제2 디바이스와 협상하는 단계는, 예를 들어, 제1 디바이스로부터 제2 디바이스로, 제2 디바이스에 서비스 능력 계층(service capability layer, "SCL")을 등록하는 것을 요청하는 제1 메시지를 송신하는 단계를 포함할 수 있고, 제1 메시지는 관리 프로토콜의 유형을 정의하는 속성 및 속성에 할당된 제1 값을 포함하고 있다. 제2 디바이스와 협상하는 단계는 또한 제1 메시지에 응답하여 송신된 제2 메시지를, 제2 디바이스로부터 제1 디바이스에서, 수신하는 단계를 포함할 수 있다. 제2 메시지는 관리 프로토콜의 유형을 정의하는 속성에 할당된 제2 값을 포함할 수 있다.
하나 이상의 실시예에서, 제2 디바이스와 협상하는 단계는 SCL의 등록에 대한 업데이트를 요청하는 제3 메시지를, 제2 디바이스로부터 제1 디바이스에서, 수신하는 단계를 추가로 포함할 수 있고, 제3 메시지는 관리 프로토콜의 유형을 정의하는 속성에 할당된 제2 값을 포함하고 있다.
대안으로서, 제2 디바이스와 협상하는 단계는 제1 디바이스로부터 제2 디바이스로, 제2 디바이스에서 SCL에 객체를 생성하는 것을 요청하는 제1 메시지를 송신하는 단계를 포함할 수 있다. 이것을 용이하게 해주기 위해, 제1 메시지는 관리 프로토콜의 유형을 정의하는 속성 및 속성에 할당된 제1 값을 포함할 수 있다. 제2 디바이스와 협상하는 단계는 제1 메시지에 응답하여 송신된 제2 메시지를, 제2 디바이스로부터 제1 디바이스에서, 수신하는 단계를 추가로 포함할 수 있다. 제2 메시지는 속성에 할당된 제2 값을 포함할 수 있다.
다른 대안으로서, 제2 디바이스와 협상하는 단계는 제1 디바이스로부터 제2 디바이스로, 제2 디바이스에서 SCL에 있는 객체에 대한 업데이트를 요청하는 제1 메시지를 송신하는 단계를 포함할 수 있다. 제1 메시지는 관리 프로토콜의 유형을 정의하는 속성을 식별해주는 식별자 및 속성에 할당된 제1 값을 포함할 수 있다. 제2 디바이스와 협상하는 단계는 또한 제1 메시지에 응답하여 송신된 제2 메시지를, 제2 디바이스로부터 제1 디바이스에서, 수신하는 단계를 포함할 수 있다. 제2 메시지는 속성에 할당된 제2 값을 포함할 수 있다.
또 다른 대안에서, 제2 디바이스와 협상하는 단계는 제2 디바이스에서 SCL에 있는 객체에 대한 업데이트를 요청하는 제1 메시지를, 제2 디바이스로부터 제1 디바이스에서, 수신하는 단계를 포함할 수 있다. 업데이트를 용이하게 해주기 위해, 제1 메시지는 관리 프로토콜의 유형을 정의하는 속성을 식별해주는 식별자 및 속성에 할당된 제1 값을 포함할 수 있다. 제2 디바이스와 협상하는 단계는 또한 제1 메시지에 응답하여, 제1 디바이스로부터 제2 디바이스로 제2 메시지를 송신하는 단계를 포함할 수 있다. 제2 메시지는 속성에 할당된 제2 값을 포함할 수 있다.
다른 대안에서, 제2 디바이스와 협상하는 단계는 제1 디바이스로부터 제3 디바이스로, 제2 디바이스를 발견하라는 제1 메시지를 송신하는 단계를 포함할 수 있다. 제1 메시지는 관리 프로토콜의 유형을 정의하는 속성 및 속성에 할당된 제1 값을 포함할 수 있다. 제2 디바이스와 협상하는 단계는 또한 제1 메시지에 응답하여 송신된 제2 메시지를, 제3 디바이스로부터 제1 디바이스에서, 수신하는 단계를 포함할 수 있다. 이 제2 메시지는 프로토콜의 유형을 정의하는 속성에 할당된 제2 값을 포함할 수 있다. 속성에 할당된 제2 값은 제2 디바이스의 SCL로부터 획득될 수 있다. 제2 디바이스와 협상하는 단계는 제1 및 제2 값이 같은 경우 제1 디바이스의 SCL을 등록하기 위한 제2 디바이스를 선택하는 단계를 추가로 포함할 수 있다.
관리 프로토콜의 유형은 "SNMP"(Simple Network Management Protocol), "BBF"(Broadband Forums) TR-069 CPE WAN 관리 프로토콜 및 OMA(Open Mobile Alliance) DM(Device Management) 프로토콜 중 임의의 것일 수 있다.
제2 시스템에서 xREM을 수행하는 방법의 추가의 예가 개시되어 있다. 이 방법은 제1 논리 계층에 따라 엔터티를 관리하는 관리 프로토콜의 유형을 제2 디바이스에 알려주는 단계를 포함할 수 있다.
xREM을 수행하는 방법의 다른 예가 개시되어 있다. 이 방법은 제1 디바이스가 제3 디바이스의 xREM에 대한 권한을 제1 디바이스에 위임하라는 요청을 제2 디바이스로부터 수신하는 단계를 포함할 수 있고; 요청에 응답하여, 제2 디바이스는 권한을 제1 디바이스에 넘길 수 있다. 권한을 획득한 후에, 제1 디바이스는 제3 디바이스에 대한 권한을 실행할 수 있다.
하나 이상의 실시예에서, 방법은 RESTful 메소드를 수행하라는 요청을, 제2 엔터티로부터 제1 엔터티에서, 수신하는 단계를 포함할 수 있다. 제1 엔터티는 명령을 정의하는 리소스("command 리소스")의 데이터 구조체를 포함시킬 수 있다. 요청은 command 리소스를 식별해주는 식별자 및 명령을 실행하기 위한 정보를 포함할 수 있다. 이 방법은 또한 식별자 및 명령을 실행하기 위한 정보의 함수로서 명령을 실행하는 단계를 포함할 수 있다. 식별자는 URI(uniform resource identifier), 링크 및 주소 중 임의의 것일 수 있다.
하나 이상의 실시예에서, 제1 엔터티는, 각각, 제1 및 제2 command 리소스의 제1 및 제2 데이터 구조체를 포함할 수 있고, 식별자는 제2 리소스에 대한 포인터를 포함하고 및/또는 그 포인터일 수 있다.
하나 이상의 실시예에서, 방법은 RESTful 메소드를 수행하라는 요청을, 제2 엔터티로부터 제1 엔터티에서, 수신하는 단계를 포함할 수 있다. 제1 엔터티는 명령을 정의하는 command 리소스의 데이터 구조체를 포함시킬 수 있다. 요청은 command 리소스를 식별해주는 식별자 및 명령을 실행하기 위한 정보를 포함할 수 있다. 이 방법은 또한 요청에 응답하여, 리소스의 제1 인스턴스를 발생하는 단계, 리소스의 제1 인스턴스를 식별해주기 위해 식별자를 업데이트하는 단계, 및 식별자 및 명령을 실행하기 위한 정보의 함수로서 명령을 실행하는 단계를 포함할 수 있다.
하나 이상의 실시예에서, 방법은 RESTful 메소드를 수행하라는 제1 요청을, 제2 엔터티로부터 제1 엔터티에서, 수신하는 단계를 포함할 수 있다. 제1 엔터티는 command 리소스의 데이터 구조체를 포함시킬 수 있고, 제1 요청은 command 리소스를 식별해주는 제1 식별자 및 명령을 실행하기 위한 제1 정보를 포함할 수 있다. 이 방법은 또한 제1 요청에 응답하여, command 리소스의 제1 인스턴스를 발생하는 단계; command 리소스의 제1 인스턴스를 식별해주기 위해 제1 식별자를 업데이트하는 단계; 및 RESTful 메소드를 수행하라는 제2 요청을, 제2 엔터티로부터 제1 엔터티에서, 수신하는 단계를 포함할 수 있다. 제2 요청은 command 리소스를 식별해주는 제2 식별자 및 명령을 실행하기 위한 제2 정보를 포함할 수 있다. 이 방법은 제2 요청에 응답하여, command 리소스의 제2 인스턴스를 발생하는 단계; command 리소스의 제2 인스턴스를 식별해주기 위해 제2 식별자를 업데이트하는 단계; 제1 식별자 및 명령을 실행하기 위한 제1 정보의 함수로서 명령을 실행하는 단계; 및 제2 식별자 및 명령을 실행하기 위한 제2 정보의 함수로서 명령을 실행하는 단계를 추가로 포함할 수 있다.
일 실시예에서, M2M(machine-to-machine) 통신을 위한 프로토콜에 따라 xREM을 수행하는 방법이 개시되어 있다. 이 방법은 RESTful 메소드를 수행하라는 요청("RESTful 메소드 요청")을, 제2 엔터티로부터 제1 엔터티에서, 수신하는 단계를 포함할 수 있다. 제1 엔터티는 RESTful 메소드에 의해 수정가능한 데이터 구조체를 포함시킬 수 있다. 이 데이터 구조체는, 예를 들어, 서비스 능력 계층("SCL")을 나타내는 데이터 구조체 - 예를 들어, 본 명세서에서 sclbase 등이라고 하는 임의의 데이터 구조체를 포함함 - 일 수 있다. RESTful 메소드 요청은 제1 엔터티에 의해 실행가능한 명령(이후부터 "리소스 command"라고 함)과 연관되어 있는 리소스를 식별해줄 수 있다. 이 방법은 또한 리소스 command에 따라 데이터 구조체에 대한 수정을 호출하기 위해 RESTful 메소드를 수행하는 단계를 포함할 수 있다.
하나 이상의 실시예에서, RESTful 메소드는 RESTful 메소드 CREATE, RESTful 메소드 RETRIEVE, RESTful 메소드 UPDATE 및/또는 RESTful 메소드 DELETE일 수 있다. RESTful 메소드가, 예를 들어, RESTful 메소드 CREATE인 실시예에서, RESTful 메소드를 수행하는 단계는 데이터 구조체에, 리소스 command를 나타내는 하위 데이터 구조체(이후부터, "command 리소스 구조체"라고 함)를 인스턴스화하는 단계를 포함할 수 있다.
RESTful 메소드가 RESTful 메소드 DELETE인 실시예에서, RESTful 메소드를 수행하는 단계는 데이터 구조체로부터 command 리소스 구조체를 삭제하는 단계를 포함할 수 있다. RESTful 메소드가 RESTful 메소드 RETRIEVE인 실시예에서, RESTful 메소드를 수행하는 단계는 command 리소스 구조체 및/또는 command 리소스 구조체의 상태("command 리소스 상태") 중 일부 또는 전부의 사본을 제2 엔터티로 송신하는 단계를 포함할 수 있다.
RESTful 메소드가 RESTful 메소드 UPDATE인 실시예에서, RESTful 메소드를 수행하는 단계는 명령의 상태("명령 상태")의 변경을 호출하기 위해 command 리소스 구조체를 수정하는 단계를 포함할 수 있다. 하나 이상의 실시예에서, 하위 데이터 구조체를 수정하는 단계는 명령의 실행을 호출하기 위해 command 리소스 구조체를 수정하는 단계를 포함할 수 있다. 예를 들어, command 리소스 구조체에 대한 이러한 수정을 검출하는 것에 응답하여 제1 엔터티에 의해 명령 실행이 호출될 수 있다.
하나 이상의 실시예에서, 리소스 command는 명령 실행을 호출하는 하위 리소스("서브리소스")("명령 실행 서브리소스")를 정의할 수 있다. 이 명령 실행 서브리소스는, 예를 들어, 본 명세서에서 이하에서 execEnable 등이라고 하는 서브리소스의 하나 이상의 실시예일 수 있다. command 리소스 구조체의 하나 이상의 요소("command 리소스 구조체 요소")가 명령 실행 서브리소스를 나타낼 수 있다.
하나 이상의 실시예에서, RESTful 메소드 요청은 명령 실행을 호출하기 위해 명령 실행 서브리소스를 수정하기 위한 정보를 포함할 수 있다. 이들 실시예에서, 명령 실행 서브리소스를 수정하는 단계는 명령 실행을 호출하기 위해 정보로 명령 실행 서브리소스를 나타내는 command 리소스 구조체 요소를 수정하는 단계를 포함할 수 있다.
명령 실행을 호출하기 위해 명령 실행 서브리소스를 수정하기 위한 정보는 명령 실행을 호출하기 위해 할당 및 해석될 수 있는 숫자, 정수, 문자, 코드 등일 수 있다. 예로서, 명령 실행을 호출하기 위해 명령 실행 서브리소스를 수정하기 위한 정보는 "0"일 수 있고, 따라서, "0"으로 명령 실행 서브리소스를 나타내는 command 리소스 구조체 요소를 수정하는 것은 명령 실행을 호출한다.
하나 이상의 실시예에서, 리소스 command는 명령 실행을 호출하는 속성을 정의할 수 있다. 이들 실시예에서, command 리소스 구조체 요소는 속성을 나타낼 수 있고, 이러한 요소는 식별자("속성 식별자")에 의해 식별가능할 수 있다. 이 명령 실행 속성 식별자는, 예를 들어, 본 명세서에서 이하에서 execEnable 등이라고 하는 속성의 하나 이상의 실시예일 수 있다.
RESTful 메소드 요청은 속성 식별자를 포함할 수 있다. 게다가, 속성을 나타내는 command 리소스 구조체 요소의 선택은 명령 실행을 호출할 수 있다. 명령의 실행을 호출하기 위해 command 리소스 구조체를 수정하는 단계는 속성 식별자를 사용하여 속성을 나타내는 command 리소스 구조체 요소를 선택하는 단계 - 이는 차례로 명령의 실행을 호출함 - 를 포함할 수 있다.
하나 이상의 실시예에서, command 리소스 구조체를 수정하는 단계는 명령 실행에 대한 일시정지(pause)를 호출하기 위해 command 리소스 구조체를 수정하는 단계를 포함할 수 있다. 예를 들어, command 리소스 구조체에 대한 이러한 수정을 검출하는 것에 응답하여 제1 엔터티에 의해 명령 실행에 대한 일시정지가 호출될 수 있다.
하나 이상의 실시예에서, 리소스 command는 명령 실행에 대한 일시정지를 호출하는 서브리소스를 정의할 수 있다. 이 서브리소스는, 예를 들어, 본 명세서에서 이하에서 execEnable 등이라고 하는 서브리소스의 하나 이상의 실시예일 수 있다. 하나 이상의 실시예에서, RESTful 메소드 요청은 명령 실행에 대한 일시정지를 호출하기 위해 명령 실행 서브리소스를 수정하기 위한 정보를 포함할 수 있다. 이들 실시예에서, 명령 실행에 대한 일시정지를 호출하기 위해 command 리소스 구조체를 수정하는 단계는 일시정지를 호출하기 위해 명령 실행 서브리소스를 나타내는 command 리소스 구조체 요소를 수정하는 단계를 포함할 수 있다. 명령 실행 서브리소스를 수정하기 위한 정보는 명령 실행에 대한 일시정지를 호출하기 위해 할당 및 해석될 수 있는 숫자, 정수, 문자, 코드 등일 수 있다. 예로서, 일시정지를 호출하기 위해 명령 실행 서브리소스를 수정하기 위한 정보는 "1"일 수 있고, 따라서 명령 실행에 대한 일시정지를 호출하기 위해 "1"로 명령 실행 서브리소스를 나타내는 command 리소스 구조체 요소를 수정하는 단계를 포함할 수 있다.
하나 이상의 실시예에서, 리소스 command는 명령 실행에 대한 일시정지를 호출하는 속성("실행 일시정지 속성")을 정의할 수 있다. command 리소스 구조체 요소들 중 하나 이상이 실행 일시정지 속성을 나타낼 수 있고, 이러한 요소는 대응하는 속성 식별자에 의해 식별가능할 수 있다. 이 실행 일시정지 속성은, 예를 들어, 본 명세서에서 이하에서 execPause 등이라고 하는 속성의 하나 이상의 실시예일 수 있다. RESTful 메소드 요청은 실행 일시정지 속성 식별자를 포함할 수 있다. 게다가, 실행 일시정지 속성을 나타내는 command 리소스 구조체 요소의 선택은 명령 실행에 대한 일시정지를 호출할 수 있다. 명령 실행에 대한 일시정지를 호출하기 위해 command 리소스 구조체를 수정하는 단계는 실행 일시정지 속성 식별자를 사용하여 실행 일시정지 속성을 나타내는 command 리소스 구조체 요소를 선택하는 단계 - 이는 차례로 명령 실행에 대한 일시정지를 호출함 - 를 포함할 수 있다.
하나 이상의 실시예에서, command 리소스 구조체를 수정하는 단계는 명령의 일시정지된 실행이 실행을 재개("명령 실행 재개")하게 하기 위해 command 리소스 구조체를 수정하는 단계를 포함할 수 있다. 예를 들어, 명령 실행 재개를 야기하기 위해 command 리소스 구조체에 대한 수정을 검출하는 것에 응답하여 제1 엔터티에 의해 명령 실행 재개가 호출될 수 있다.
하나 이상의 실시예에서, 리소스 command는 명령 실행 재개를 호출하는 서브리소스를 정의할 수 있다. 이 서브리소스는, 예를 들어, 본 명세서에서 이하에서 execEnable 등이라고 하는 서브리소스의 하나 이상의 실시예일 수 있다. 하나 이상의 실시예에서, RESTful 메소드 요청은 명령 실행 재개를 호출하기 위해 명령 실행 서브리소스를 수정하기 위한 정보를 포함할 수 있다. 이들 실시예에서, 명령 실행 재개를 호출하기 위해 command 리소스 구조체를 수정하는 단계는 명령 실행 재개를 호출하기 위해 명령 실행 서브리소스를 나타내는 command 리소스 구조체 요소를 수정하는 단계를 포함할 수 있다. 이 정보는 명령 실행 재개를 호출하기 위해 할당 및 해석될 수 있는 숫자, 정수, 문자, 코드 등일 수 있다. 예로서, 명령 실행 재개를 호출하기 위해 명령 실행 서브리소스를 수정하기 위한 정보는 "2"일 수 있고, 따라서 "2"로 명령 실행 재개 서브리소스를 나타내는 command 리소스 구조체 요소를 수정하는 것은 명령 실행 재개를 호출한다.
하나 이상의 실시예에서, 리소스 command는 명령 실행 재개를 호출하는 속성("실행 재개 속성")을 정의할 수 있다. command 리소스 구조체 요소들 중 하나 이상은 실행 재개 속성을 나타낼 수 있고, 이러한 요소는 대응하는 속성 식별자에 의해 식별가능할 수 있다. 이 실행 재개 속성은, 예를 들어, 본 명세서에서 이하에서 execResume 등이라고 하는 속성의 하나 이상의 실시예일 수 있다. RESTful 메소드 요청은 실행 재개 속성 식별자를 포함할 수 있다. 게다가, 실행 재개 속성을 나타내는 command 리소스 구조체 요소의 선택은 명령 실행 재개를 호출할 수 있다. 명령 실행 재개를 호출하기 위해 command 리소스 구조체를 수정하는 단계는 실행 재개 속성 식별자를 사용하여 실행 재개 속성을 나타내는 command 리소스 구조체 요소를 선택하는 단계 - 이는 차례로 명령 실행 재개를 호출함 - 를 포함할 수 있다.
하나 이상의 실시예에서, command 리소스 구조체를 수정하는 단계는 명령 실행의 취소("명령 실행 취소")를 호출하기 위해 command 리소스 구조체를 수정하는 단계를 포함할 수 있다. 예를 들어, 명령 실행 취소를 호출하기 위해 command 리소스 구조체에 대한 수정을 검출하는 것에 응답하여 제1 엔터티에 의해 명령 실행 취소가 호출될 수 있다.
하나 이상의 실시예에서, 리소스 command는 명령 실행 취소를 호출하는 서브리소스를 정의할 수 있다. 이 서브리소스는, 예를 들어, 본 명세서에서 이하에서 execEnable 등이라고 하는 서브리소스의 하나 이상의 실시예일 수 있다. 하나 이상의 실시예에서, RESTful 메소드 요청은 명령 실행 취소를 호출하기 위해 명령 실행 서브리소스를 수정하기 위한 정보를 포함할 수 있다. 이들 실시예에서, 명령 실행 취소를 호출하기 위해 command 리소스 구조체를 수정하는 단계는 명령 실행 취소를 호출하기 위해 명령 실행 서브리소스를 나타내는 command 리소스 구조체 요소를 수정하는 단계를 포함할 수 있다. 이 정보는 명령 실행 취소를 호출하기 위해 할당 및 해석될 수 있는 숫자, 정수, 문자, 코드 등일 수 있다. 예로서, 명령 실행 취소를 호출하기 위해 명령 실행 서브리소스를 수정하기 위한 정보는 "3"일 수 있고, 따라서 "3"으로 명령 실행 취소 서브리소스를 나타내는 command 리소스 구조체 요소를 수정하는 것은 명령 실행 취소를 호출한다.
하나 이상의 실시예에서, 리소스 command는 명령 실행 취소를 호출하는 속성("실행 취소 속성")을 정의할 수 있다. command 리소스 구조체 요소들 중 하나 이상은 실행 취소 속성을 나타낼 수 있고, 이러한 요소는 대응하는 속성 식별자에 의해 식별가능할 수 있다. 이 실행 취소 속성은, 예를 들어, 본 명세서에서 이하에서 execDisable 등이라고 하는 속성의 하나 이상의 실시예일 수 있다. RESTful 메소드 요청은 실행 취소 속성 식별자를 포함할 수 있다. 게다가, 실행 취소 속성을 나타내는 command 리소스 구조체 요소의 선택은 명령 실행 취소를 호출할 수 있다. 명령 실행 취소를 호출하기 위해 command 리소스 구조체를 수정하는 단계는 실행 취소 속성 식별자를 사용하여 실행 취소 속성을 나타내는 command 리소스 구조체 요소를 선택하는 단계 - 이는 차례로 명령 실행 취소를 호출함 - 를 포함할 수 있다.
RESTful 메소드가 RESTful 메소드 DELETE인 하나 이상의 실시예에서, RESTful 메소드를 수행하는 단계는 명령 실행 상태의 변경을 호출하기 위해 command 리소스 구조체를 수정하는 단계, 및 데이터 구조체로부터 command 리소스 구조체를 삭제하는 단계를 포함할 수 있다.
하나 이상의 실시예에서, command 리소스 구조체를 수정하는 단계는 명령 실행 취소를 호출하기 위해 command 리소스 구조체를 수정하는 단계를 포함할 수 있다. 명령 실행 취소를 호출하기 위해 command 리소스 구조체에 대한 수정을 검출하는 것에 응답하여 제1 엔터티에 의해 명령 실행 취소가 또한 호출될 수 있다. 다른 대안으로서, 예를 들어, RESTful 메소드 DELETE에 응답하여 제1 엔터티에 의해 명령 실행 취소가 호출될 수 있다.
하나 이상의 실시예에서, 명령 실행 취소를 호출하기 위해 command 리소스 구조체를 수정하는 단계는 상기와 같이, 명령 실행 취소를 호출하기 위해 명령 실행 서브리소스를 나타내는 command 리소스 구조체 요소를 수정하는 단계를 포함할 수 있다. 하나 이상의 실시예에서, 명령 실행 취소를 호출하기 위해 command 리소스 구조체를 수정하는 단계는 실행 취소 속성 식별자를 사용하여 실행 취소 속성을 나타내는 command 리소스 구조체 요소를 선택하는 단계 - 이는 차례로 명령 실행 취소를 호출함 - 를 포함할 수 있다.
M2M(machine-to-machine) 통신을 위한 프로토콜에 따라 원격 엔터티 관리를 수행하는 대안의 방법이 개시되어 있다. 이 방법은 RESTful 메소드 요청을, 제2 엔터티로부터 제1 엔터티에서, 수신하는 단계를 포함할 수 있다. 제1 엔터티는 RESTful 메소드에 의해 수정가능한 데이터 구조체를 포함시킬 수 있다. 데이터 구조체는 제1 리소스를 나타내는 하위 데이터 구조체를 포함할 수 있고, 여기서 제1 리소스는 command 리소스 상태를 호출하는 동작을 정의한다. 하위 데이터 구조체는 식별자에 의해 식별가능할 수 있고, 여기서 RESTful 메소드 요청은 식별자를 포함할 수 있고, 리소스 command를 식별해줄 수 있다. 이 방법은 또한 식별자 및 리소스 command에 따라 데이터 구조체에 대한 수정을 호출하기 위해 RESTful 메소드를 수행하는 단계를 포함할 수 있다.
하나 이상의 실시예에서, command 리소스 상태의 변경을 호출하는 동작은 명령 실행을 호출하거나, 명령 실행에 대한 취소를 호출하거나, 명령 실행 재개를 호출하거나, 명령 실행 취소를 호출하는 동작을 포함할 수 있다.
일 실시예에서, M2M(machine-to-machine) 통신을 위한 프로토콜에 따라 xREM을 수행하는 방법은 RESTful 메소드를 수행하라는 요청("RESTful 메소드 요청")을, 제2 엔터티로부터 제1 엔터티에서, 수신하는 단계를 포함할 수 있다. 제1 엔터티는 RESTful 메소드에 의해 수정가능한 데이터 구조체를 포함시킬 수 있다. 이 데이터 구조체는, 예를 들어, 서비스 능력 계층("SCL")을 나타내는 데이터 구조체 - 예를 들어, 본 명세서에서 sclbase 등이라고 하는 임의의 데이터 구조체를 포함함 - 일 수 있다. RESTful 메소드 요청은 제3 엔터티에 의해 실행가능한 명령(이후부터 "리소스 command"이라고 함)과 연관되어 있는 리소스를 식별해줄 수 있다. 이 방법은 또한 리소스 command에 따라 데이터 구조체에 대한 수정을 호출하기 위해 RESTful 메소드를 수행하는 단계를 포함할 수 있다.
하나 이상의 실시예에서, RESTful 메소드는 RESTful 메소드 CREATE, RESTful 메소드 RETRIEVE, RESTful 메소드 UPDATE 및/또는 RESTful 메소드 DELETE일 수 있다. RESTful 메소드가, 예를 들어, RESTful 메소드 CREATE인 실시예에서, RESTful 메소드를 수행하는 단계는 데이터 구조체에, 리소스 command를 나타내는 하위 데이터 구조체(이후부터, "command 리소스 구조체"라고 함)를 인스턴스화하는 단계를 포함할 수 있다.
RESTful 메소드가 RESTful 메소드 DELETE인 실시예에서, RESTful 메소드를 수행하는 단계는 데이터 구조체로부터 command 리소스 구조체를 삭제하는 단계를 포함할 수 있다. RESTful 메소드가 RESTful 메소드 RETRIEVE인 실시예에서, RESTful 메소드를 수행하는 단계는 command 리소스 구조체 및/또는 command 리소스 구조체의 상태("command 리소스 상태") 중 일부 또는 전부의 사본을 제2 엔터티로 송신하는 단계를 포함할 수 있다.
RESTful 메소드가 RESTful 메소드 UPDATE인 실시예에서, RESTful 메소드를 수행하는 단계는 명령의 상태("명령 상태")의 변경을 호출하기 위해 command 리소스 구조체를 수정하는 단계를 포함할 수 있다. 하나 이상의 실시예에서, 하위 데이터 구조체를 수정하는 단계는 명령의 실행을 호출하기 위해 command 리소스 구조체를 수정하는 단계를 포함할 수 있다. 예를 들어, command 리소스 구조체에 대한 이러한 수정을 검출하는 것에 응답하여 제1 엔터티에 의해 명령 실행이 호출될 수 있다.
하나 이상의 실시예에서, 리소스 command는 명령 실행을 호출하는 하위 리소스("서브리소스")("명령 실행 서브리소스")를 정의할 수 있다. 이 명령 실행 서브리소스는, 예를 들어, 본 명세서에서 이하에서 execEnable 등이라고 하는 서브리소스의 하나 이상의 실시예일 수 있다. command 리소스 구조체의 하나 이상의 요소("command 리소스 구조체 요소")가 명령 실행 서브리소스를 나타낼 수 있다.
하나 이상의 실시예에서, RESTful 메소드 요청은 명령 실행을 호출하기 위해 명령 실행 서브리소스를 수정하기 위한 정보를 포함할 수 있다. 이들 실시예에서, 명령 실행 서브리소스를 수정하는 단계는 명령 실행을 호출하기 위해 정보로 명령 실행 서브리소스를 나타내는 command 리소스 구조체 요소를 수정하는 단계를 포함할 수 있다.
명령 실행을 호출하기 위해 명령 실행 서브리소스를 수정하기 위한 정보는 명령 실행을 호출하기 위해 할당 및 해석될 수 있는 숫자, 정수, 문자, 코드 등일 수 있다. 예로서, 명령 실행을 호출하기 위해 명령 실행 서브리소스를 수정하기 위한 정보는 "0"일 수 있고, 따라서 "0"으로 명령 실행 서브리소스를 나타내는 command 리소스 구조체 요소를 수정하는 것은 명령 실행을 호출한다.
하나 이상의 실시예에서, 리소스 command는 명령 실행을 호출하는 속성을 정의할 수 있다. 이들 실시예에서, command 리소스 구조체 요소는 속성을 나타낼 수 있고, 이러한 요소는 식별자("속성 식별자")에 의해 식별가능할 수 있다. 이 명령 실행 속성 식별자는, 예를 들어, 본 명세서에서 이하에서 execEnable 등이라고 하는 속성의 하나 이상의 실시예일 수 있다.
RESTful 메소드 요청은 속성 식별자를 포함할 수 있다. 게다가, 속성을 나타내는 command 리소스 구조체 요소의 선택은 명령 실행을 호출할 수 있다. 명령의 실행을 호출하기 위해 command 리소스 구조체를 수정하는 단계는 속성 식별자를 사용하여 속성을 나타내는 command 리소스 구조체 요소를 선택하는 단계 - 이는 차례로 명령의 실행을 호출함 - 를 포함할 수 있다.
하나 이상의 실시예에서, command 리소스 구조체를 수정하는 단계는 명령 실행에 대한 일시정지(pause)를 호출하기 위해 command 리소스 구조체를 수정하는 단계를 포함할 수 있다. 예를 들어, command 리소스 구조체에 대한 이러한 수정을 검출하는 것에 응답하여 제1 엔터티에 의해 명령 실행에 대한 일시정지가 호출될 수 있다.
하나 이상의 실시예에서, 리소스 command는 명령 실행에 대한 일시정지를 호출하는 서브리소스를 정의할 수 있다. 이 서브리소스는, 예를 들어, 본 명세서에서 이하에서 execEnable 등이라고 하는 서브리소스의 하나 이상의 실시예일 수 있다. 하나 이상의 실시예에서, RESTful 메소드 요청은 명령 실행에 대한 일시정지를 호출하기 위해 명령 실행 서브리소스를 수정하기 위한 정보를 포함할 수 있다. 이들 실시예에서, 명령 실행에 대한 일시정지를 호출하기 위해 command 리소스 구조체를 수정하는 단계는 일시정지를 호출하기 위해 명령 실행 서브리소스를 나타내는 command 리소스 구조체 요소를 수정하는 단계를 포함할 수 있다. 명령 실행 서브리소스를 수정하기 위한 정보는 명령 실행에 대한 일시정지를 호출하기 위해 할당 및 해석될 수 있는 숫자, 정수, 문자, 코드 등일 수 있다. 예로서, 일시정지를 호출하기 위해 명령 실행 서브리소스를 수정하기 위한 정보는 "1"일 수 있고, 따라서 명령 실행에 대한 일시정지를 호출하기 위해 "1"로 명령 실행 서브리소스를 나타내는 command 리소스 구조체 요소를 수정하는 단계를 포함할 수 있다.
하나 이상의 실시예에서, 리소스 command는 명령 실행에 대한 일시정지를 호출하는 속성("실행 일시정지 속성")을 정의할 수 있다. command 리소스 구조체 요소들 중 하나 이상이 실행 일시정지 속성을 나타낼 수 있고, 이러한 요소는 대응하는 속성 식별자에 의해 식별가능할 수 있다. 이 실행 일시정지 속성은, 예를 들어, 본 명세서에서 이하에서 execPause 등이라고 하는 속성의 하나 이상의 실시예일 수 있다. RESTful 메소드 요청은 실행 일시정지 속성 식별자를 포함할 수 있다. 게다가, 실행 일시정지 속성을 나타내는 command 리소스 구조체 요소의 선택은 명령 실행에 대한 일시정지를 호출할 수 있다. 명령 실행에 대한 일시정지를 호출하기 위해 command 리소스 구조체를 수정하는 단계는 실행 일시정지 속성 식별자를 사용하여 실행 일시정지 속성을 나타내는 command 리소스 구조체 요소를 선택하는 단계 - 이는 차례로 명령 실행에 대한 일시정지를 호출함 - 를 포함할 수 있다.
하나 이상의 실시예에서, command 리소스 구조체를 수정하는 단계는 명령의 일시정지된 실행이 실행을 재개("명령 실행 재개")하게 하기 위해 command 리소스 구조체를 수정하는 단계를 포함할 수 있다. 예를 들어, 명령 실행 재개를 야기하기 위해 command 리소스 구조체에 대한 수정을 검출하는 것에 응답하여 제1 엔터티에 의해 명령 실행 재개가 호출될 수 있다.
하나 이상의 실시예에서, 리소스 command는 명령 실행 재개를 호출하는 서브리소스를 정의할 수 있다. 이 서브리소스는, 예를 들어, 본 명세서에서 이하에서 execEnable 등이라고 하는 서브리소스의 하나 이상의 실시예일 수 있다. 하나 이상의 실시예에서, RESTful 메소드 요청은 명령 실행 재개를 호출하기 위해 명령 실행 서브리소스를 수정하기 위한 정보를 포함할 수 있다. 이들 실시예에서, 명령 실행 재개를 호출하기 위해 command 리소스 구조체를 수정하는 단계는 명령 실행 재개를 호출하기 위해 명령 실행 서브리소스를 나타내는 command 리소스 구조체 요소를 수정하는 단계를 포함할 수 있다. 이 정보는 명령 실행 재개를 호출하기 위해 할당 및 해석될 수 있는 숫자, 정수, 문자, 코드 등일 수 있다. 예로서, 명령 실행 재개를 호출하기 위해 명령 실행 서브리소스를 수정하기 위한 정보는 "2"일 수 있고, 따라서 "2"로 명령 실행 재개 서브리소스를 나타내는 command 리소스 구조체 요소를 수정하는 것은 명령 실행 재개를 호출한다.
하나 이상의 실시예에서, 리소스 command는 명령 실행 재개를 호출하는 속성("실행 재개 속성")을 정의할 수 있다. command 리소스 구조체 요소들 중 하나 이상이 실행 재개 속성을 나타낼 수 있고, 이러한 요소는 대응하는 속성 식별자에 의해 식별가능할 수 있다. 이 실행 재개 속성은, 예를 들어, 본 명세서에서 이하에서 execResume 등이라고 하는 속성의 하나 이상의 실시예일 수 있다. RESTful 메소드 요청은 실행 재개 속성 식별자를 포함할 수 있다. 게다가, 실행 재개 속성을 나타내는 command 리소스 구조체 요소의 선택은 명령 실행 재개를 호출할 수 있다. 명령 실행 재개를 호출하기 위해 command 리소스 구조체를 수정하는 단계는 실행 재개 속성 식별자를 사용하여 실행 재개 속성을 나타내는 command 리소스 구조체 요소를 선택하는 단계 - 이는 차례로 명령 실행 재개를 호출함 - 를 포함할 수 있다.
하나 이상의 실시예에서, command 리소스 구조체를 수정하는 단계는 명령 실행의 취소("명령 실행 취소")를 호출하기 위해 command 리소스 구조체를 수정하는 단계를 포함할 수 있다. 예를 들어, 명령 실행 취소를 호출하기 위해 command 리소스 구조체에 대한 수정을 검출하는 것에 응답하여 제1 엔터티에 의해 명령 실행 취소가 호출될 수 있다.
하나 이상의 실시예에서, 리소스 command는 명령 실행 취소를 호출하는 서브리소스를 정의할 수 있다. 이 서브리소스는, 예를 들어, 본 명세서에서 이하에서 execEnable 등이라고 하는 서브리소스의 하나 이상의 실시예일 수 있다. 하나 이상의 실시예에서, RESTful 메소드 요청은 명령 실행 취소를 호출하기 위해 명령 실행 서브리소스를 수정하기 위한 정보를 포함할 수 있다. 이들 실시예에서, 명령 실행 취소를 호출하기 위해 command 리소스 구조체를 수정하는 단계는 명령 실행 취소를 호출하기 위해 명령 실행 서브리소스를 나타내는 command 리소스 구조체 요소를 수정하는 단계를 포함할 수 있다. 이 정보는 명령 실행 취소를 호출하기 위해 할당 및 해석될 수 있는 숫자, 정수, 문자, 코드 등일 수 있다. 예로서, 명령 실행 취소를 호출하기 위해 명령 실행 서브리소스를 수정하기 위한 정보는 "3"일 수 있고, 따라서 "3"으로 명령 실행 취소 서브리소스를 나타내는 command 리소스 구조체 요소를 수정하는 것은 명령 실행 취소를 호출한다.
하나 이상의 실시예에서, 리소스 command는 명령 실행 취소를 호출하는 속성("실행 취소 속성")을 정의할 수 있다. command 리소스 구조체 요소들 중 하나 이상은 실행 취소 속성을 나타낼 수 있고, 이러한 요소는 대응하는 속성 식별자에 의해 식별가능할 수 있다. 이 실행 취소 속성은, 예를 들어, 본 명세서에서 이하에서 execDisable 등이라고 하는 속성의 하나 이상의 실시예일 수 있다. RESTful 메소드 요청은 실행 취소 속성 식별자를 포함할 수 있다. 게다가, 실행 취소 속성을 나타내는 command 리소스 구조체 요소의 선택은 명령 실행 취소를 호출할 수 있다. 명령 실행 취소를 호출하기 위해 command 리소스 구조체를 수정하는 단계는 실행 취소 속성 식별자를 사용하여 실행 취소 속성을 나타내는 command 리소스 구조체 요소를 선택하는 단계 - 이는 차례로 명령 실행 취소를 호출함 - 를 포함할 수 있다.
RESTful 메소드가 RESTful 메소드 DELETE인 하나 이상의 실시예에서, RESTful 메소드를 수행하는 단계는 명령 실행 상태의 변경을 호출하기 위해 command 리소스 구조체를 수정하는 단계, 및 데이터 구조체로부터 command 리소스 구조체를 삭제하는 단계를 포함할 수 있다.
하나 이상의 실시예에서, command 리소스 구조체를 수정하는 단계는 명령 실행 취소를 호출하기 위해 command 리소스 구조체를 수정하는 단계를 포함할 수 있다. 명령 실행 취소를 호출하기 위해 command 리소스 구조체에 대한 수정을 검출하는 것에 응답하여 제1 엔터티에 의해 명령 실행 취소가 또한 호출될 수 있다. 다른 대안으로서, 예를 들어, RESTful 메소드 DELETE에 응답하여 제1 엔터티에 의해 명령 실행 취소가 호출될 수 있다.
하나 이상의 실시예에서, 명령 실행 취소를 호출하기 위해 command 리소스 구조체를 수정하는 단계는 상기와 같이, 명령 실행 취소를 호출하기 위해 명령 실행 서브리소스를 나타내는 command 리소스 구조체 요소를 수정하는 단계를 포함할 수 있다. 하나 이상의 실시예에서, 명령 실행 취소를 호출하기 위해 command 리소스 구조체를 수정하는 단계는 실행 취소 속성 식별자를 사용하여 실행 취소 속성을 나타내는 command 리소스 구조체 요소를 선택하는 단계 - 이는 차례로 명령 실행 취소를 호출함 - 를 포함할 수 있다.
M2M(machine-to-machine) 통신을 위한 프로토콜에 따라 원격 엔터티 관리를 수행하는 대안의 방법이 개시되어 있다. 이 방법은 RESTful 메소드 요청을, 제2 엔터티로부터 제1 엔터티에서, 수신하는 단계를 포함할 수 있다. 제1 엔터티는 RESTful 메소드에 의해 수정가능한 데이터 구조체를 포함시킬 수 있다. 데이터 구조체는 제1 리소스를 나타내는 하위 데이터 구조체를 포함할 수 있고, 여기서 제1 리소스는 command 리소스 상태를 호출하는 동작을 정의한다. 하위 데이터 구조체는 식별자에 의해 식별가능할 수 있고, 여기서 RESTful 메소드 요청은 식별자를 포함할 수 있고, 리소스 command을 식별해줄 수 있다. 이 방법은 또한 식별자 및 리소스 command에 따라 데이터 구조체에 대한 수정을 호출하기 위해 RESTful 메소드를 수행하는 단계를 포함할 수 있다.
하나 이상의 실시예에서, command 리소스 상태의 변경을 호출하는 동작은 명령 실행을 호출하거나, 명령 실행에 대한 취소를 호출하거나, 명령 실행 재개를 호출하거나, 명령 실행 취소를 호출하는 동작을 포함할 수 있다.
하나 이상의 실시예에서, 명령의 상태의 변경을 호출하는 하위 데이터 구조체들 중 임의의 것(예컨대, 이하에 기술되는 바와 같이, <command>, <commandInstance> 또는 <requestInstance>)은 이러한 하위 데이터 구조체가 종속되어 있는 데이터 구조체로부터 임포트(import)된 속성, 서브리소스, 파라미터 및 인수(argument) 중 임의의 것을 포함할 수 있다.
일 실시예에서, 방법은 디바이스의 주소 매핑을 유지하는 단계, 및 주소 매핑을 사용하여 통지를 디바이스로 송신하는 단계를 포함할 수 있다. 디바이스는 디바이스 관리 디바이스일 수 있다.
일 실시예에서, 방법은 디바이스 관리 게이트웨이에서, M2M 디바이스를 관리하기 위해 투명 모드 및 프록시 모드 중 하나를 사용하여 서비스 능력(D)을 갖는 M2M 디바이스를 관리하는 단계를 포함할 수 있다.
일 실시예에서, 방법은 디바이스 관리 게이트웨이에서, M2M 디바이스를 관리하는 단계, 및 적응 모드(adaptation mode)를 사용하여 M2M 디바이스를 관리하는 단계를 포함할 수 있다.
일 실시예에서, 방법은 디바이스 관리 게이트웨이에서, 비-ETSI M2M 디바이스를 관리하는 단계, 및 적응 모드를 사용하여 비-ETSI M2M 디바이스를 관리하는 단계를 포함할 수 있다.
일 실시예에서, 방법은 게이트웨이에서, 디바이스의 주소 매핑을 유지하는 단계; 및 주소 매핑을 사용하여 통지를 디바이스로 송신하는 단계를 포함할 수 있다.
선행 실시예에서와 같은 방법으로서, 디바이스가 디바이스 관리 디바이스인 방법.
선행 실시예들 중 적어도 하나의 실시예에서와 같은 방법으로서, 디바이스가 서비스 능력(D)으로 구성될 수 있는 것인 방법.
일 실시예에서, 방법은 디바이스 관리 게이트웨이에서, 서비스 능력(D)을 갖는 M2M 디바이스를 관리하는 단계; 및 투명 모드 및 프록시 모드 중 하나를 사용하여 M2M 디바이스를 관리하는 단계를 포함할 수 있다.
일 실시예에서, 방법은 디바이스 관리 게이트웨이에서, M2M 디바이스를 관리하는 단계; 및 적응 모드를 사용하여 M2M 디바이스를 관리하는 단계를 포함할 수 있다.
일 실시예에서, 방법은 디바이스 관리 게이트웨이에서, 비-ETSI M2M 디바이스를 관리하는 단계; 및 적응 모드를 사용하여 비-ETSI M2M 디바이스를 관리하는 단계를 포함할 수 있다.
일 실시예에서, M2M 영역 네트워크 및 M2M 디바이스를 데이터 모델링하는 데이터 구조체는 etsiAreaNwkInfo를 포함하는 적어도 하나의 관리 객체; etsiAreaNwkDeviceInventory를 포함할 수 있는 적어도 하나의 관리 객체; etsiAreaNwkDeviceGroups를 포함하는 적어도 하나의 관리 객체; etsiAreaNwkGroupOperations를 포함하는 적어도 하나의 관리 객체; 및 etsiSensors를 포함하는 적어도 하나의 관리 객체를 포함한다. 데이터 구조체는 디바이스 인벤토리 및 구성 관리, 영역 네트워크 구성 관리, 영역 네트워크 성능 관리, 또는 디바이스의 그룹 관리 중 적어도 하나를 제공할 수 있다.
일 실시예에서, M2M(machine-to-machine) 영역 네트워크 및 M2M 디바이스에 대한 데이터 모델링 방법은 M2M 네트워크 및 적어도 하나의 디바이스에 대한 적어도 하나의 관리 객체를 포함하는 M2M에 대한 데이터 모델을 관리하는 단계를 포함할 수 있다.
선행 실시예에서와 같은 방법으로서, 관리하는 단계가 디바이스 인벤토리 및 구성 관리를 제공할 수 있는 것인 방법.
선행 실시예들 중 적어도 하나의 실시예에서와 같은 방법으로서, 관리하는 단계가 영역 네트워크 구성 관리를 제공할 수 있는 것인 방법.
선행 실시예들 중 적어도 하나의 실시예에서와 같은 방법으로서, 관리하는 단계가 영역 네트워크 성능 관리를 제공할 수 있는 것인 방법.
선행 실시예들 중 적어도 하나의 실시예에서와 같은 방법으로서, 관리하는 단계가 디바이스의 그룹 관리를 제공할 수 있는 것인 방법.
선행 실시예들 중 적어도 하나의 실시예에서와 같은 방법으로서, 적어도 하나의 관리 객체가 etsiAreaNwkInfo를 포함할 수 있는 것인 방법.
선행 실시예들 중 적어도 하나의 실시예에서와 같은 방법으로서, 적어도 하나의 관리 객체가 etsiAreaNwkDeviceInventory를 포함할 수 있는 것인 방법.
선행 실시예들 중 적어도 하나의 실시예에서와 같은 방법으로서, 적어도 하나의 관리 객체가 etsiAreaNwkDeviceGroups를 포함할 수 있는 것인 방법.
선행 실시예들 중 적어도 하나의 실시예에서와 같은 방법으로서, 적어도 하나의 관리 객체가 etsiAreaNwkGroupOperations를 포함할 수 있는 것인 방법.
선행 실시예들 중 적어도 하나의 실시예에서와 같은 방법으로서, 적어도 하나의 관리 객체가 etsiSensors를 포함할 수 있는 것인 방법.
선행 실시예들 중 적어도 하나의 실시예에서와 같은 방법으로서, 적어도 하나의 관리 객체가 서브리소스를 포함할 수 있는 것인 방법.
선행 실시예들 중 적어도 하나의 실시예에서와 같은 방법으로서, 적어도 하나의 관리 객체가 다른 관리 객체의 서브리소스를 포함할 수 있는 것인 방법.
선행 실시예에서와 같은 방법으로서, etsiAreaNwkInfo가 서브리소스로서 areaNwkInstance를 포함할 수 있는 것인 방법.
선행 실시예들 중 적어도 하나의 실시예에서와 같은 방법으로서, areaNwkInstance가 서브리소스로서 areaNwkID, areaNwkType, workmgChannelFrequency, 및 addressMode 중 임의의 것을 포함할 수 있는 것인 방법.
선행 실시예들 중 적어도 하나의 실시예에서와 같은 방법으로서, etsiAreaNwkDeviceInventory가 그룹으로서 deviceInstance 및 deviceApplicationList 중 임의의 것을 포함할 수 있는 것인 방법.
선행 실시예들 중 적어도 하나의 실시예에서와 같은 방법으로서, deviceInstance가 서브리소스로서 deviceGroupList, etsiBattery, etsiMemory, 및 etsiSensor 중 적어도 하나를 포함할 수 있는 것인 방법.
선행 실시예들 중 적어도 하나의 실시예에서와 같은 방법으로서, deviceInstance가 서브리소스로서 deviceType, deviceID, addressType, areaNwkID, internal address, external address, sleeplnterval, sleepDuration, status, maxRtrAdvertisements, minDelayBetweenRas, maxRaDelayTime, tenativeNceLifetime, hopLimit, rtrSolicitationlnvterval, maxRtrSolicitatios, 또는 maxRtrSolicitationlnterval 중 적어도 하나를 포함할 수 있는 것인 방법.
선행 실시예들 중 적어도 하나의 실시예에서와 같은 방법으로서, etsiAreaNwkDeviceGroups가 서브리소스로서 deviceGroupInstance를 포함할 수 있는 것인 방법.
선행 실시예들 중 적어도 하나의 실시예에서와 같은 방법으로서, deviceGroupInstance가 서브리소스로서 groupID, groupType, groupSize, members, 또는 condition 중 적어도 하나를 포함할 수 있는 것인 방법.
선행 실시예들 중 적어도 하나의 실시예에서와 같은 방법으로서, etsiAreaNwkGroupOperations가 서브리소스로서 operationInstance를 포함하는 것인 방법.
선행 실시예들 중 적어도 하나의 실시예에서와 같은 방법으로서, operationInstance가 서브리소스로서 groupID, enable, disable, results 또는 description 중 적어도 하나를 포함할 수 있는 것인 방법.
선행 실시예들 중 적어도 하나의 실시예에서와 같은 방법으로서, etsiSensors가 서브리소스로서 sensorInstance를 포함할 수 있는 것인 방법.
선행 실시예들 중 적어도 하나의 실시예에서와 같은 방법으로서, sensorInstance가 서브리소스로서 sensorID, sensorType, manufacturer, 또는 operations 중 적어도 하나를 포함할 수 있는 것인 방법.
선행 실시예들 중 적어도 하나의 실시예에서와 같은 방법으로서, operations이 서브리소스로서 enable, disable 또는 result 중 적어도 하나를 포함할 수 있는 것인 방법.
일 실시예에서, M2M(machine-to-machine) 영역 네트워크 및 M2M 디바이스를 데이터 모델링하는 리소스 구조체는 etsiAreaNwkInfo를 포함하는 적어도 하나의 관리 객체; etsiAreaNwkDeviceInventory를 포함하는 적어도 하나의 관리 객체; etsiAreaNwkDeviceGroups를 포함하는 적어도 하나의 관리 객체; etsiAreaNwkGroupOperations를 포함하는 적어도 하나의 관리 객체; 및 etsiSensors를 포함하는 적어도 하나의 관리 객체를 포함할 수 있다. 리소스 구조체는 디바이스 인벤토리 및 구성 관리, 영역 네트워크 구성 관리, 영역 네트워크 성능 관리, 또는 디바이스의 그룹 관리 중 적어도 하나를 제공한다.
일 실시예에서, M2M 영역 네트워크 및 M2M 디바이스를 데이터 모델링하는 데이터 구조체는 etsiAreaNwkInfo를 포함하는 적어도 하나의 관리 객체; etsiAreaNwkDeviceInventory를 포함하는 적어도 하나의 관리 객체; etsiAreaNwkDeviceGroups를 포함하는 적어도 하나의 관리 객체; etsiGroupMgmtOperations를 포함하는 적어도 하나의 관리 객체; 및 etsiSensors를 포함하는 적어도 하나의 관리 객체를 포함한다. 데이터 구조체는 디바이스 인벤토리 및 구성 관리, 영역 네트워크 구성 관리, 영역 네트워크 성능 관리, 또는 디바이스의 그룹 관리 중 적어도 하나를 제공한다.
일 실시예에서, M2M(machine-to-machine) 영역 네트워크 및 M2M 디바이스에 대한 데이터 모델링 방법은 M2M 네트워크 및 적어도 하나의 디바이스에 대한 적어도 하나의 관리 객체를 포함하는 M2M에 대한 데이터 모델을 관리하는 단계를 포함할 수 있다.
선행 실시예에서와 같은 방법으로서, 관리하는 단계가 디바이스 인벤토리 및 구성 관리를 제공하는 것인 방법.
선행 실시예들 중 적어도 하나의 실시예에서와 같은 방법으로서, 관리하는 단계가 영역 네트워크 구성 관리를 제공하는 것인 방법.
선행 실시예들 중 적어도 하나의 실시예에서와 같은 방법으로서, 관리하는 단계가 영역 네트워크 성능 관리를 제공하는 것인 방법.
선행 실시예들 중 적어도 하나의 실시예에서와 같은 방법으로서, 관리하는 단계가 디바이스의 그룹 관리를 제공하는 것인 방법.
선행 실시예들 중 적어도 하나의 실시예에서와 같은 방법으로서, 적어도 하나의 관리 객체가 etsiAreaNwkInfo를 포함하는 것인 방법.
선행 실시예들 중 적어도 하나의 실시예에서와 같은 방법으로서, 적어도 하나의 관리 객체가 etsiAreaNwkDeviceInventory를 포함하는 것인 방법.
선행 실시예들 중 적어도 하나의 실시예에서와 같은 방법으로서, 적어도 하나의 관리 객체가 etsiAreaNwkDeviceGroups를 포함하는 것인 방법.
선행 실시예들 중 적어도 하나의 실시예에서와 같은 방법으로서, 적어도 하나의 관리 객체가 etsiGroupMgmtOperations를 포함하는 것인 방법.
선행 실시예들 중 적어도 하나의 실시예에서와 같은 방법으로서, 적어도 하나의 관리 객체가 etsiSensors를 포함하는 것인 방법.
선행 실시예들 중 적어도 하나의 실시예에서와 같은 방법으로서, 적어도 하나의 관리 객체가 서브리소스를 포함하는 것인 방법.
선행 실시예들 중 적어도 하나의 실시예에서와 같은 방법으로서, 적어도 하나의 관리 객체가 다른 관리 객체의 서브리소스를 포함하는 것인 방법.
선행 실시예들 중 적어도 하나의 실시예에서와 같은 방법으로서, etsiAreaNwkInfo가 서브리소스로서 areaNwkInstance를 포함하는 것인 방법.
선행 실시예들 중 적어도 하나의 실시예에서와 같은 방법으로서, areaNwkInstance가 서브리소스로서 areaNwkID, areaNwkType, workingChannelFrequency, addressMode, sleeplnterval, sleepDuration, numOfDevices, 및 attachedDevices 중 적어도 하나를 포함하는 것인 방법.
선행 실시예들 중 적어도 하나의 실시예에서와 같은 방법으로서, etsiAreaNwkDeviceInventory가 그룹으로서 deviceInstance 및 areaNwkInstance 중 적어도 하나를 포함하는 것인 방법.
선행 실시예들 중 적어도 하나의 실시예에서와 같은 방법으로서, deviceInstance가 서브리소스로서 groups, deviceType, deviceID, addressType, areaNwkID, internal Address, external Address, sleeplnterval, sleepDuration, status, etsiBattery, etsiMemory, etsiSensor, blockSize, 및 MTU 중 적어도 하나를 포함하는 것인 방법.
선행 실시예들 중 적어도 하나의 실시예에서와 같은 방법으로서, deviceInstance가 서브리소스로서 6LoWPAN, Wi-Fi, RFID, 및 ZigBee 중 적어도 하나를 포함하는 것인 방법.
선행 실시예들 중 적어도 하나의 실시예에서와 같은 방법으로서, etsiAreaNwkDeviceGroup이 서브리소스로서 deviceGroupInstance를 포함하는 것인 방법.
선행 실시예들 중 적어도 하나의 실시예에서와 같은 방법으로서, deviceGroupInstance가 서브리소스로서 groupID, groupType, groupSize, members, 또는 condition 중 적어도 하나를 포함하는 것인 방법.
선행 실시예들 중 적어도 하나의 실시예에서와 같은 방법으로서, etsiGroupMgmtOperations가 서브리소스로서 groups, subscriptions, 및 operationInstance 중 적어도 하나를 포함하는 것인 방법.
선행 실시예들 중 적어도 하나의 실시예에서와 같은 방법으로서, operationInstance가 서브리소스로서 groupID, execEnable, execDisable, execPause, execResume, execStatus, OperationID, execResults, 및 execParameters 중 적어도 하나를 포함하는 것인 방법.
선행 실시예들 중 적어도 하나의 실시예에서와 같은 방법으로서, etsiSensors가 서브리소스로서 sensorInstance를 포함하는 것인 방법.
선행 실시예들 중 적어도 하나의 실시예에서와 같은 방법으로서, sensorInstance가 서브리소스로서 sensorID, sensorType, manufacturer, 또는 operations 중 적어도 하나를 포함하는 것인 방법.
선행 실시예들 중 적어도 하나의 실시예에서와 같은 방법으로서, operations가 서브리소스로서 enable, disable 또는 result 중 적어도 하나를 포함하는 것인 방법.
일 실시예에서, 무선 송수신 유닛은 선행 실시예들 중 임의의 실시예에서와 같은 방법을 구현하도록 구성되어 있을 수 있다.
일 실시예에서, 기지국은 선행 실시예들 중 임의의 실시예에서와 같은 방법을 구현하도록 구성되어 있을 수 있다.
일 실시예에서, 유형의 컴퓨터 판독가능 저장 매체는, 선행 실시예들 중 임의의 실시예에서와 같은 방법을 수행하기 위해, 컴퓨팅 디바이스의 메모리에 로드가능하고 그에 의해 실행가능한 실행가능 명령어를 저장하고 있을 수 있다.
일 실시예에서, M2M(machine-to-machine) 영역 네트워크 및 M2M 디바이스를 데이터 모델링하는 리소스 구조체는 etsiAreaNwkInfo를 포함하는 적어도 하나의 관리 객체; etsiAreaNwkDeviceInventory를 포함하는 적어도 하나의 관리 객체; etsiAreaNwkDeviceGroups를 포함하는 적어도 하나의 관리 객체; etsiGroupMgmtOperations를 포함하는 적어도 하나의 관리 객체; 및 etsiSensors를 포함하는 적어도 하나의 관리 객체를 포함할 수 있다. 리소스 구조체는 디바이스 인벤토리 및 구성 관리, 영역 네트워크 구성 관리, 영역 네트워크 성능 관리, 또는 디바이스의 그룹 관리 중 적어도 하나를 제공한다.
본 발명의 범위를 벗어나지 않고 앞서 기술한 방법, 장치 및 시스템의 변형례가 가능하다. 적용될 수 있는 아주 다양한 실시예를 바탕으로, 예시된 실시예가 단지 예시적인 것이고 이하의 청구항의 범위를 제한하는 것으로 보아서는 안된다는 것을 잘 알 것이다. 예를 들어, 본 명세서에 기술되어 있는 예시적인 실시예는 임의의 적절한 전압을 제공하는 배터리 등의 임의의 적절한 전압원을 포함하거나 그를 사용하여 이용될 수 있는 핸드헬드 디바이스를 포함한다.
특징 및 요소가 특정의 조합으로 앞서 기술되어 있지만, 당업자라면 각각의 특징 또는 요소가 단독으로 또는 다른 특징 및 요소와 임의의 조합으로 사용될 수 있다는 것을 잘 알 것이다 그에 부가하여, 본 명세서에 기술된 방법이 컴퓨터 또는 프로세서에서 실행하기 위해 컴퓨터 판독가능 매체에 포함되어 있는 컴퓨터 프로그램, 소프트웨어, 또는 펌웨어로 구현될 수 있다. 컴퓨터 판독가능 매체의 일례는 전자 신호(유선 또는 무선 연결을 통해 전송됨) 및 컴퓨터 판독가능 저장 매체를 포함한다. 컴퓨터 판독가능 저장 매체의 일례로는 ROM(read only memory), RAM(random access memory), 레지스터, 캐시 메모리, 반도체 메모리 장치, 내장형 하드 디스크 및 이동식 디스크 등의 자기 매체, 광자기 매체, 그리고 CD-ROM 디스크 및 DVD(digital versatile disk) 등의 광 매체가 있지만, 이들로 제한되지 않는다. 소프트웨어와 연관된 프로세서는 WTRU, UE, 단말, 기지국, RNC, 또는 임의의 호스트 컴퓨터에서 사용하기 위한 무선 주파수 송수신기를 구현하는 데 사용될 수 있다.
더욱이, 앞서 기술된 실시예에서, 처리 플랫폼, 컴퓨팅 시스템, 제어기, 및 프로세서를 포함하는 기타 장치가 언급되었다. 이들 장치는 적어도 하나의 중앙 처리리 장치(CPU) 및 메모리를 포함할 수 있다. 컴퓨터 프로그래밍의 분야의 당업자의 실무에 따르면, 동작 또는 명령어의 작용 및 심볼 표현에 대한 참조가 다양한 CPU 및 메모리에 의해 수행될 수 있다. 이러한 작용 및 동작 또는 명령어는 "실행", "컴퓨터 실행" 또는 "CPU 실행"되는 것으로 말해질 수 있다.
기술 분야의 당업자라면 작용 및 심볼로 표현된 동작 또는 명려어가 CPU에 의한 전기 신호의 조작을 포함한다는 것을 잘 알 것이다. 전기 시스템은 전기 신호의 얻어진 변환 또는 감소 및 메모리 시스템 내의 메모리 장소에의 데이터 비트의 유지를 야기할 수 있는 데이터 비트를 표현하고 그로써 CPU의 동작은 물론 신호의 다른 처리를 재구성 또는 다른 방식으로 변경한다. 데이터 비트가 유지되는 메모리 장소는 데이터 비트에 대응하는 또는 그를 나타내는 특정의 전기, 자기, 광학 또는 유기 특성을 가지는 물리적 장소이다. 예시적인 실시예가 상기 언급한 플랫폼 또는 CPU로 제한되지 않는다는 것과 다른 플랫폼 및 CPU가 기술된 방법을 지원할 수 있다는 것을 잘 알 것이다.
데이터 비트는 또한 CPU에 의해 판독가능한 자기 디스크, 광 디스크, 및 임의의 다른 휘발성[예컨대, 랜덤 액세스 메모리(RAM)] 또는 비휘발성[예컨대, 판독 전용 메모리(ROM)] 대용량 저장 시스템을 비롯한 컴퓨터 판독가능 매체 상에 유지될 수 있다. 컴퓨터 판독가능 매체는 처리 시스템 상에만 존재하거나 처리 시스템에 로컬이거나 원격일 수 있는 다수의 상호연결된 처리 시스템 간에 분산되어 있는 협력하는 또는 상호연결된 컴퓨터 판독가능 매체를 포함할 수 있다. 예시적인 실시예가 상기 언급한 메모리로 제한되지 않는다는 것과 다른 플랫폼 및 메모리가 기술된 방법을 지원할 수 있다는 것을 잘 알 것이다.
본 출원의 설명에서 사용되는 요소, 작용 또는 명령어가, 그러한 것으로 명시적으로 기술되어 있지 않는 한, 본 발명에 중요하거나 필수적인 것으로 해석되어서는 안된다. 또한, 본 명세서에서 사용되는 바와 같이, 단수 형태는 하나 이상의 항목을 포함하기 위한 것이다. 단지 하나의 항목이 의도되어 있는 경우, "하나" 또는 유사한 표현이 사용된다. 게다가, 복수의 항목 및/또는 복수의 항목 카테고리의 목록의 다음에 오는 " ~ 중 임의의 것"이라는 용어는, 본 명세서에서 사용되는 바와 같이, "~ 중 임의의 것", "~의 임의의 조합", "~ 중 임의의 다수", 및/또는 "항목들 및/또는 항목 카테고리들 중 다수의 임의의 조합"을 개별적으로 또는 다른 항목 및/또는 다른 항목 카테고리와 함께 포함하기 위한 것이다. 게다가, 본 명세서에서 사용되는 바와 같이, "세트" 및/또는 모음이라는 용어는 0개를 비롯한 임의의 수의 항목을 포함하기 위한 것이다. 게다가, 본 명세서에서 사용되는 바와 같이, "수"라는 용어는 0을 비롯한 임의의 수를 포함하기 위한 것이다.
더욱이, 청구항이, 그러한 취지로 언급되어 있지 않는 한, 기술된 순서 또는 요소로 제한되는 것으로 해석되어서는 안된다. 그에 부가하여, 임의의 청구항에서 "수단"이라는 용어의 사용은 미국 특허법 제112조 6항을 원용하기 위한 것이며, "수단"이라는 단어가 없는 임의의 청구항은 그와 같이 의도되어 있지 않다.

Claims (37)

  1. M2M(machine-to-machine) 서버에서 구현되는 방법에 있어서,
    상기 M2M 서버는 원격 엔터티 관리(remote entity management, REM)를 위한 서비스 능력(service capability, SC) 및 REM을 수행하는 REM 리소스 구조체(REM resource structure)를 가지며, 상기 방법은,
    상기 REM 리소스 구조체의 하위(subordinate) 리소스 구조체의 제1 요소를 식별해주는 식별자를 포함하는 RESTful 메소드(method)를, M2M 네트워크 응용 프로그램(application)으로부터, 수신하는 단계 - 상기 하위 리소스 구조체는 관리 명령에 대해 구성되어 있고, 상기 제1 요소는 상기 관리 명령의 실행 상태 및 실행 모드 중 임의의 것을 설정하는 함수를 나타냄 -;
    상기 함수를, 디바이스 관리 서버를 통해 액세스가능한 디바이스에 대한 디바이스 관리 명령으로 변환(translating)하는 단계;
    상기 디바이스 관리 명령을 상기 디바이스 관리 서버로 송신하는 단계;
    상기 디바이스 관리 명령을 호출하는 것과 연관되어 있는 정보를 포함하는 응답을, 상기 디바이스 관리 서버로부터, 수신하는 단계;
    상기 디바이스 관리 명령을 호출하는 것과 연관되어 있는 상기 정보를 상기 하위 리소스 구조체의 제2 요소에 저장하는 단계 - 상기 제2 요소는 상기 제1 요소에 링크되어 있음 -; 및
    상기 제2 요소로부터의 상기 정보를 상기 M2M 네트워크 응용 프로그램에 제공하는 단계를 포함하는, M2M 서버에서 구현되는 방법.
  2. 제1항에 있어서, 상기 M2M 서버 및 관리 명령은 제1 프로토콜 세트에 따라 구성되어 있고, 상기 디바이스 관리 서버 및 디바이스 관리 명령은 제2 프로토콜 세트에 따라 구성되어 있으며, 상기 제2 프로토콜 세트는 상기 제1 프로토콜 세트와 상이한 적어도 하나의 프로토콜을 포함하는 것인, M2M 서버에서 구현되는 방법.
  3. 제1항에 있어서, 상기 REM 리소스 구조체는 디바이스 관리 계층에 따라 M2M 디바이스 및 M2M 게이트웨이 중 임의의 것의 REM을 수행하는 다른 하위 리소스 구조체를 포함하는 것인, M2M 서버에서 구현되는 방법.
  4. 제1항에 있어서,
    다른 RESTful 메소드를, 상기 M2M 네트워크 응용 프로그램으로부터, 수신하는 단계 - 상기 다른 RESTful 메소드는 다른 하위 리소스 구조체의 제1 요소를 식별해주는 식별자를 포함하고, 상기 다른 하위 리소스 구조체는 관리 명령에 대해 구성되어 있으며, 상기 제1 요소는 상기 관리 명령의 실행 상태 및 실행 모드 중 임의의 것을 설정하는 함수를 나타냄 -; 및
    상기 RESTful 메소드에 응답하여 M2M 디바이스 또는 M2M 게이트웨이의 REM을 수행하는 단계를 추가로 포함하는, M2M 서버에서 구현되는 방법.
  5. 제4항에 있어서, M2M 디바이스 또는 M2M 게이트웨이의 REM을 수행하는 단계는,
    관리 명령의 실행 상태 및 실행 모드 중 임의의 것을 설정하는 함수에 따라 상기 관리 명령의 현재의 실행 상태 또는 실행 모드 중 임의의 것을 변경하라는 지시를, 상기 M2M 디바이스 또는 M2M 게이트웨이로, 송신하는 단계;
    상기 관리 명령의 현재의 실행 상태 및 실행 모드 중 임의의 것을 변경하는 것과 연관되어 있는 정보를 포함하는 응답을, 상기 M2M 디바이스 또는 M2M 게이트웨이로부터, 수신하는 단계;
    상기 관리 명령의 현재의 실행 상태 및 실행 모드 중 임의의 것을 변경하는 것과 연관되어 있는 상기 정보를 상기 다른 하위 리소스 구조체의 제2 요소에 저장하는 단계 - 상기 제2 요소는 상기 제1 요소에 링크되어 있음 -; 및
    상기 제2 요소로부터의 상기 정보를 상기 M2M 네트워크 응용 프로그램에 제공하는 단계를 포함하는 것인, M2M 서버에서 구현되는 방법.
  6. 제5항에 있어서, 상기 다른 하위 리소스 구조체는 상기 M2M 디바이스 또는 M2M 게이트웨이와 연관되어 있고, 상기 M2M 디바이스 또는 M2M 게이트웨이의 REM을 수행하는 단계는 상기 M2M 서버로 하여금 상기 관리 명령의 현재의 실행 상태 또는 실행 모드 중 임의의 것을 변경하라는 지시를 송신하게 하기 위해 상기 다른 하위 리소스 구조체를 조작하는 단계를 포함하는 것인, M2M 서버에서 구현되는 방법.
  7. 제1항에 있어서, 상기 식별자는 상기 REM 리소스 구조체의 하위 리소스 구조체의 상기 제1 요소의 URI(uniform resource identifier)를 포함하는 것인, M2M 서버에서 구현되는 방법.
  8. 제1항 또는 제7항에 있어서, 상기 REM 리소스 구조체의 하위 리소스 구조체의 상기 제1 요소는 서브리소스(sub-resource) 및 속성 중 임의의 것을 포함하는 것인, M2M 서버에서 구현되는 방법.
  9. 제1항 또는 제7항에 있어서, 상기 함수는 실행(run) 함수, 일시정지(pause) 함수, 취소(cancel) 함수, 및 재개(resume) 함수 중 임의의 것을 포함하는 것인, M2M 서버에서 구현되는 방법.
  10. 제1항 또는 제7항에 있어서, 상기 RESTful 메소드는 CREATE RESTful 메소드, RETRIEVE RESTful 메소드, UPDATE RESTful 메소드, 및 DELETE RESTful 메소드 중 적어도 하나를 포함하는 것인, M2M 서버에서 구현되는 방법.
  11. M2M(machine-to-machine) 서버에서 구현되는 방법에 있어서,
    상기 M2M 서버는 원격 엔터티 관리(remote entity management, REM)를 위한 서비스 능력(service capability, SC) 및 REM을 수행하는 REM 리소스 구조체를 가지며, 상기 방법은,
    상기 REM 리소스 구조체의 하위 리소스 구조체의 요소를 식별해주는 식별자를 포함하는 RESTful 메소드를, M2M 네트워크 응용 프로그램으로부터, 수신하는 단계 - 상기 하위 리소스 구조체는 관리 명령에 대해 구성되어 있고, 상기 요소는 상기 관리 명령의 실행 상태 및 실행 모드 중 임의의 것을 설정하는 함수를 나타냄 -;
    상기 하위 리소스 구조체의 인스턴스(instance)를 생성하는 단계;
    상기 함수를, 디바이스 관리 서버를 통해 액세스가능한 디바이스에 대한 디바이스 관리 명령으로 변환하는 단계;
    상기 디바이스 관리 명령을 상기 디바이스 관리 서버로 송신하는 단계;
    상기 디바이스 관리 명령을 호출하는 것과 연관되어 있는 정보를 포함하는 응답을, 상기 디바이스 관리 서버로부터, 수신하는 단계;
    상기 디바이스 관리 명령을 호출하는 것과 연관되어 있는 상기 정보를 상기 하위 리소스 구조체의 인스턴스의 요소에 저장하는 단계; 및
    상기 하위 리소스 구조체의 인스턴스의 요소로부터의 상기 정보를 상기 M2M 네트워크 응용 프로그램에 제공하는 단계를 포함하는 것인, M2M 서버에서 구현되는 방법.
  12. 제11항에 있어서, 상기 하위 리소스 구조체의 인스턴스를 생성하는 단계는 상기 RESTful 메소드에 응답하여 상기 하위 리소스 구조체의 인스턴스를 생성하는 단계를 포함하는 것인, M2M 서버에서 구현되는 방법.
  13. 제11항 또는 제12항에 있어서, 상기 식별자는 상기 REM 리소스 구조체의 하위 리소스 구조체의 상기 요소의 URI(uniform resource identifier)를 포함하는 것인, M2M 서버에서 구현되는 방법.
  14. 제11항 또는 제12항에 있어서, 상기 REM 리소스 구조체의 하위 리소스 구조체의 상기 요소는 서브리소스 및 속성 중 임의의 것을 포함하는 것인, M2M 서버에서 구현되는 방법.
  15. 제11항 또는 제12항에 있어서, 상기 함수는 실행 함수, 일시정지 함수, 취소 함수, 및 재개 함수 중 임의의 것을 포함하는 것인, M2M 서버에서 구현되는 방법.
  16. 제11항 또는 제12항에 있어서, 상기 RESTful 메소드는 CREATE RESTful 메소드, RETRIEVE RESTful 메소드, UPDATE RESTful 메소드, 및 DELETE RESTful 메소드 중 적어도 하나를 포함하는 것인, M2M 서버에서 구현되는 방법.
  17. 원격 엔터티 관리(REM)를 위한 서비스 능력 및 REM을 수행하는 하위 리소스 구조체를 가지는 REM 리소스 구조체로 구성된(configured) M2M(machine-to-machine) 서버에 있어서,
    상기 M2M 서버는,
    상기 REM 리소스 구조체의 하위 리소스 구조체의 제1 요소를 식별해주는 식별자를 포함하는 RESTful 메소드를, M2M 네트워크 응용 프로그램으로부터, 수신하고 - 상기 하위 리소스 구조체는 관리 명령에 대해 구성되어 있고, 상기 제1 요소는 상기 관리 명령의 실행 상태 및 실행 모드 중 임의의 것을 설정하는 함수를 나타냄 -;
    상기 함수를, 디바이스 관리 서버를 통해 액세스가능한 디바이스에 대한 디바이스 관리 명령으로 변환하며;
    상기 디바이스 관리 명령을 디바이스 관리 서버로 송신하고;
    상기 디바이스 관리 명령을 호출하는 것과 연관되어 있는 정보를 포함하는 응답을, 상기 디바이스 관리 서버로부터, 수신하며;
    상기 디바이스 관리 명령을 호출하는 것과 연관되어 있는 상기 정보를 상기 하위 리소스 구조체의 제2 요소에 저장하고 - 상기 제2 요소는 상기 제1 요소에 링크되어 있음 -;
    상기 제2 요소로부터의 상기 정보를 상기 M2M 네트워크 응용 프로그램에 제공하도록 구성되어 있는 것인 M2M 서버.
  18. 제17항에 있어서, 상기 M2M 서버 및 관리 명령은 제1 프로토콜 세트에 따라 구성되어 있고, 상기 디바이스 관리 서버 및 디바이스 관리 명령은 제2 프로토콜 세트에 따라 구성되어 있으며, 상기 제2 프로토콜 세트는 상기 제1 프로토콜 세트와 상이한 적어도 하나의 프로토콜을 포함하는 것인 M2M 서버.
  19. 제17항에 있어서, 상기 REM 리소스 구조체는 디바이스 관리 계층에 따라 M2M 디바이스 및 M2M 게이트웨이 중 임의의 것의 REM을 수행하는 다른 하위 리소스 구조체를 포함하는 것인 M2M 서버.
  20. 제17항에 있어서, 상기 M2M 서버는 또한,
    다른 RESTful 메소드를, 상기 M2M 네트워크 응용 프로그램으로부터, 수신하고 - 상기 다른 RESTful 메소드는 다른 하위 리소스 구조체의 제1 요소를 식별해주는 식별자를 포함하고, 상기 하위 리소스 구조체는 관리 명령에 대해 구성되어 있으며, 상기 제1 요소는 상기 관리 명령의 실행 상태 및 실행 모드 중 임의의 것을 설정하는 함수를 나타냄 -;
    상기 RESTful 메소드에 응답하여 M2M 디바이스 또는 M2M 게이트웨이의 REM을 수행하도록 구성되어 있는 것인 M2M 서버.
  21. 제20항에 있어서, 상기 M2M 서버는, 적어도 부분적으로,
    관리 명령의 실행 상태 및 실행 모드 중 임의의 것을 설정하는 함수에 따라 상기 관리 명령의 현재의 실행 상태 또는 실행 모드 중 임의의 것을 변경하라는 지시를, 상기 M2M 디바이스 또는 M2M 게이트웨이로, 송신하고;
    상기 관리 명령의 현재의 실행 상태 및 실행 모드 중 임의의 것을 변경하는 것과 연관되어 있는 정보를 포함하는 응답을, 상기 M2M 디바이스 또는 M2M 게이트웨이로부터, 수신하며;
    상기 관리 명령의 현재의 실행 상태 및 실행 모드 중 임의의 것을 변경하는 것과 연관되어 있는 상기 정보를 상기 다른 하위 리소스 구조체의 제2 요소에 저장하고 - 상기 제2 요소는 상기 제1 요소에 링크되어 있음 -;
    상기 제2 요소로부터의 상기 정보를 상기 M2M 네트워크 응용 프로그램에 제공함으로써,
    M2M 디바이스 또는 M2M 게이트웨이의 REM을 수행하도록 구성되어 있는 것인 M2M 서버.
  22. 제20항에 있어서, 상기 다른 하위 리소스 구조체는 상기 M2M 디바이스 또는 M2M 게이트웨이와 연관되어 있고,
    상기 M2M 서버는, 적어도 부분적으로,
    상기 M2M 서버로 하여금 상기 관리 명령의 현재의 실행 상태 또는 실행 모드 중 임의의 것을 변경하라는 지시를 송신하게 하기 위해 상기 다른 하위 리소스 구조체를 조작함으로써,
    상기 M2M 디바이스 또는 M2M 게이트웨이의 REM을 수행하도록 구성되어 있는 것인 M2M 서버.
  23. 제17항에 있어서, 상기 식별자는 상기 REM 리소스 구조체의 하위 리소스 구조체의 상기 제1 요소의 URI(uniform resource identifier)를 포함하는 것인 M2M 서버.
  24. 제17항 또는 제23항에 있어서, 상기 REM 리소스 구조체의 하위 리소스 구조체의 상기 제1 요소는 서브리소스 및 속성 중 임의의 것을 포함하는 것인 M2M 서버.
  25. 제17항 또는 제23항에 있어서, 상기 함수는 실행 함수, 일시정지 함수, 취소 함수, 및 재개 함수 중 임의의 것을 포함하는 것인 M2M 서버.
  26. 제17항 또는 제23항에 있어서, 상기 RESTful 메소드는 CREATE RESTful 메소드, RETRIEVE RESTful 메소드, UPDATE RESTful 메소드, 및 DELETE RESTful 메소드 중 적어도 하나를 포함하는 것인 M2M 서버.
  27. 원격 엔터티 관리(REM)를 위한 서비스 능력 및 REM을 수행하는 하위 리소스 구조체를 가지는 REM 리소스 구조체로 구성된(configured) M2M(machine-to-machine) 서버에 있어서,
    상기 M2M 서버는,
    상기 REM 리소스 구조체의 하위 리소스 구조체의 요소를 식별해주는 식별자를 포함하는 RESTful 메소드를, M2M 네트워크 응용 프로그램으로부터, 수신하고 -상기 하위 리소스 구조체는 관리 명령에 대해 구성되어 있으며, 상기 요소는 상기 관리 명령의 실행 상태 및 실행 모드 중 임의의 것을 설정하는 함수를 나타냄 -;
    상기 하위 리소스 구조체의 인스턴스를 생성하며;
    상기 함수를, 디바이스 관리 서버를 통해 액세스가능한 디바이스에 대한 디바이스 관리 명령으로 변환하고;
    상기 디바이스 관리 명령을 상기 디바이스 관리 서버로 송신하며;
    상기 디바이스 관리 명령을 호출하는 것과 연관되어 있는 정보를 포함하는 응답을, 상기 디바이스 관리 서버로부터, 수신하고;
    상기 디바이스 관리 명령을 호출하는 것과 연관되어 있는 상기 정보를 상기 하위 리소스 구조체의 인스턴스의 요소에 저장하며;
    상기 하위 리소스 구조체의 인스턴스의 요소로부터의 상기 정보를 상기 M2M 네트워크 응용 프로그램에 제공하도록 구성되어 있는 것인 M2M 서버.
  28. 제27항에 있어서, 상기 M2M 서버는 상기 RESTful 메소드에 응답하여 상기 하위 리소스 구조체의 인스턴스를 생성하도록 구성되어 있는 것인 M2M 서버.
  29. 제27항 또는 제28항에 있어서, 상기 식별자는 상기 REM 리소스 구조체의 하위 리소스 구조체의 상기 요소의 URI(uniform resource identifier)를 포함하는 것인 M2M 서버.
  30. 제27항 또는 제28항에 있어서, 상기 REM 리소스 구조체의 하위 리소스 구조체의 상기 요소는 서브리소스 및 속성 중 임의의 것을 포함하는 것인 M2M 서버.
  31. 제27항 또는 제28항에 있어서, 상기 함수는 실행 함수, 일시정지 함수, 취소 함수, 및 재개 함수 중 임의의 것을 포함하는 것인 M2M 서버.
  32. 제27항 또는 제28항에 있어서, 상기 RESTful 메소드는 CREATE RESTful 메소드, RETRIEVE RESTful 메소드, UPDATE RESTful 메소드, 및 DELETE RESTful 메소드 중 적어도 하나를 포함하는 것인 M2M 서버.
  33. 삭제
  34. 삭제
  35. 삭제
  36. 삭제
  37. 삭제
KR1020137024052A 2011-02-11 2012-02-10 Ｍ2ｍ(ｍａｃｈｉｎｅ-ｔｏ-ｍａｃｈｉｎｅ) 엔터티를 관리하는 시스템, 방법 및 장치 KR101963466B1 (ko)

Applications Claiming Priority (17)

Application Number Priority Date Filing Date Title
US201161441911P 2011-02-11 2011-02-11
US61/441,911 2011-02-11
US201161444323P 2011-02-18 2011-02-18
US61/444,323 2011-02-18
US201161452422P 2011-03-14 2011-03-14
US61/452,422 2011-03-14
US201161485631P 2011-05-13 2011-05-13
US61/485,631 2011-05-13
US201161496812P 2011-06-14 2011-06-14
US61/496,812 2011-06-14
US201161501046P 2011-06-24 2011-06-24
US201161500798P 2011-06-24 2011-06-24
US61/501,046 2011-06-24
US61/500,798 2011-06-24
US201161508564P 2011-07-15 2011-07-15
US61/508,564 2011-07-15
PCT/US2012/024634 WO2012109531A2 (en) 2011-02-11 2012-02-10 Systems, methods and apparatus for managing machine-to-machine (m2m) entities

Publications (2)

Publication Number Publication Date
KR20140008373A KR20140008373A (ko) 2014-01-21
KR101963466B1 true KR101963466B1 (ko) 2019-03-28

Family

ID=45815952

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020137024052A KR101963466B1 (ko) 2011-02-11 2012-02-10 Ｍ2ｍ(ｍａｃｈｉｎｅ-ｔｏ-ｍａｃｈｉｎｅ) 엔터티를 관리하는 시스템, 방법 및 장치

Country Status (9)

Country Link
US (3) US9426222B2 (ko)
EP (2) EP2854423B1 (ko)
JP (3) JP5894193B2 (ko)
KR (1) KR101963466B1 (ko)
CN (2) CN107529693B (ko)
HK (1) HK1192677A1 (ko)
MY (1) MY162193A (ko)
TW (2) TWI642290B (ko)
WO (1) WO2012109531A2 (ko)

Families Citing this family (121)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102833742B (zh) * 2011-06-17 2016-03-30 华为技术有限公司 机器类通信设备组算法的协商方法和设备
KR101822940B1 (ko) * 2011-12-12 2018-01-29 엘지전자 주식회사 수행 시간에 기초하여 장치 관리 명령을 수행하는 방법 및 장치
CN103200209B (zh) * 2012-01-06 2018-05-25 华为技术有限公司 成员资源的访问方法、群组服务器和成员设备
EP3425942A1 (en) * 2012-01-13 2019-01-09 Iot Holdings, Inc. Method and apparatus for supporting machine-to-machine communications
US9270638B2 (en) * 2012-01-20 2016-02-23 Cisco Technology, Inc. Managing address validation states in switches snooping IPv6
JP5657604B2 (ja) * 2012-05-17 2015-01-21 株式会社日立ソリューションズ 端末管理システム、管理サーバ及び方法
KR101453154B1 (ko) * 2012-05-30 2014-10-23 모다정보통신 주식회사 Ｍ2ｍ 통신에서 리소스 접근 권한 설정 방법
US20130324121A1 (en) * 2012-05-30 2013-12-05 Samsung Sds Co., Ltd. Apparatus and method for machine-to-machine communications
KR101453155B1 (ko) * 2012-05-30 2014-10-23 모다정보통신 주식회사 Ｍ2ｍ 통신에서 리소스 접근 권한 설정 방법
US8984111B2 (en) * 2012-06-15 2015-03-17 Symantec Corporation Techniques for providing dynamic account and device management
US20140003339A1 (en) * 2012-07-02 2014-01-02 Puneet Jain Machine-to-machine (m2m) device and methods for 3gpp and etsi m2m interworking
FI125393B (en) 2012-07-17 2015-09-30 Arm Finland Oy Procedure, device and system for use in a web service
FI125254B (en) 2012-07-17 2015-08-14 Arm Finland Oy Method and device in a network service system
WO2014042446A2 (ko) * 2012-09-12 2014-03-20 엘지전자 주식회사 무선 통신 시스템에서 특정 리소스에 대한 특정 권한 획득을 요청하기 위한 방법 및 장치
CN103685210B (zh) * 2012-09-26 2018-02-13 中兴通讯股份有限公司 终端的注册方法及装置
CN103780663B (zh) 2012-10-26 2019-05-07 中兴通讯股份有限公司 一种终端外设的远程管理方法、装置和系统
CN103856497B (zh) * 2012-11-29 2017-06-06 华为终端有限公司 家庭网络中的终端管理方法、设备和家庭网络
US9262242B2 (en) * 2012-12-31 2016-02-16 Verizon Patent And Licensing Inc. Machine-to-machine (“M2M”) device client systems, methods, and interfaces
TWI488473B (zh) * 2013-01-02 2015-06-11 Ind Tech Res Inst 自動配置伺服器及其用戶終端設備的管理方法
US9717027B2 (en) 2013-01-11 2017-07-25 Lg Electronics Inc. Method for changing gateway in machine-to-machine (M2M) system and device therefore
KR101432128B1 (ko) * 2013-01-29 2014-08-21 주식회사 케이티 Ｍ２ｍ 네트워크상에서의 리소스를 디바이스 오브젝트로 추상화하는 ｍ２ｍm 플랫폼
KR101983993B1 (ko) * 2013-02-04 2019-05-31 주식회사 케이티 게이트웨이 기반의 ｍ２ｍ 디바이스 리소스 동적 그룹핑 방법
KR101986850B1 (ko) * 2013-02-04 2019-06-07 주식회사 케이티 Ｍ２ｍ정보 관리 방법 및 그 장치
JP6255422B2 (ja) * 2013-02-19 2017-12-27 インターデイジタル パテント ホールディングス インコーポレイテッド 未来のモノのインターネットのための情報モデリング
CN104662858B (zh) * 2013-02-20 2017-10-17 华为技术有限公司 机器通信操作触发方法和装置
JP2016526207A (ja) * 2013-05-06 2016-09-01 コンヴィーダ ワイヤレス， エルエルシー モノのインターネットのための知的交渉サービス
WO2014181941A1 (ko) * 2013-05-09 2014-11-13 전자부품연구원 개방형 ｍ２ｍ 시스템 및 그의 리소스 관리와 인터페이스 방법
EP2996433A4 (en) * 2013-05-10 2016-05-25 Alcatel Lucent METHOD, APPARATUS AND USER EQUIPMENT FOR NEIGHBOR DISCOVERY WITHOUT NETWORK COVERAGE
CN104168597A (zh) * 2013-05-17 2014-11-26 中兴通讯股份有限公司 监控处理方法、装置及m2m网关
US10708341B2 (en) * 2013-05-21 2020-07-07 Convida Wireless, Llc Lightweight IoT information model
JP6306171B2 (ja) * 2013-06-24 2018-04-04 ゼットティーイー（ユーエスエー）インコーポレーテッド Ｍ２ｍノード上で複数のｍ２ｍサービスプロバイダをサポートする方法及び装置
EP3025524A2 (en) 2013-07-25 2016-06-01 Convida Wireless, LLC Service layer southbound interface and quality of service
CN104349497B (zh) 2013-08-01 2019-10-08 北京三星通信技术研究有限公司 Ue间接近发现方法和设备
JP6279718B2 (ja) * 2013-09-20 2018-02-14 コンヴィーダ ワイヤレス， エルエルシー 関心に基づく拡張ｍ２ｍコンテンツ管理
KR102035359B1 (ko) * 2013-10-14 2019-10-24 전자부품연구원 리소스 접근 방법 및 이를 적용한 시스템
KR102345346B1 (ko) * 2013-12-01 2021-12-30 엘지전자 주식회사 무선 통신 시스템에서 특정 리소스의 관리를 위한 방법 및 장치
WO2015103744A1 (zh) 2014-01-08 2015-07-16 华为技术有限公司 数据发送方法、通用业务实体及底层网络实体
WO2015110348A1 (en) * 2014-01-22 2015-07-30 Nec Europe Ltd. Method for configuring an m2m system
CN104811922A (zh) * 2014-01-29 2015-07-29 中兴通讯股份有限公司 一种相邻节点注册方法和装置、跨节点注册方法和系统
KR101922100B1 (ko) * 2014-02-10 2018-11-27 지티이 코포레이션 M2m 통신을 도모하는 방법 및 장치
TWI531197B (zh) * 2014-02-14 2016-04-21 天鉞電子股份有限公司 子母式點對點連線系統、子母式點對點連線方法及其電腦應用程式
US9684708B2 (en) 2014-02-21 2017-06-20 International Business Machines Corporation Representing a machine-to-machine device model based on ontological relationships
EP3108675B1 (en) * 2014-02-21 2017-08-23 Telefonaktiebolaget LM Ericsson (publ) Pico-rru-based network implementation for facilitating 6lowpan data access
US9369919B2 (en) 2014-02-21 2016-06-14 Telefonaktiebolaget Lm Ericsson (Publ) Pico-RRU-based network implementation for facilitating 6LoWPAN data access
JP6514315B2 (ja) * 2014-03-18 2019-05-15 中興通訊股▲ふん▼有限公司Ｚｔｅ Ｃｏｒｐｏｒａｔｉｏｎ マシン対マシンネットワークにおけるリソースおよび属性管理
JP6342014B2 (ja) * 2014-04-09 2018-06-13 コンヴィーダ ワイヤレス， エルエルシー サービスイネーブラ機能
US9351323B2 (en) * 2014-04-23 2016-05-24 Grand Mate Co., Ltd. Method of registering electric devices in wireless control system
CN105100002B (zh) * 2014-05-05 2019-05-07 中兴通讯股份有限公司 属性的操作方法及装置
US9876653B1 (en) 2014-05-13 2018-01-23 Senseware, Inc. System, method and apparatus for augmenting a building control system domain
US10263841B1 (en) 2014-05-13 2019-04-16 Senseware, Inc. System, method and apparatus for configuring a node in a sensor network
US10833893B2 (en) 2014-05-13 2020-11-10 Senseware, Inc. System, method and apparatus for integrated building operations management
US10687231B1 (en) 2014-05-13 2020-06-16 Senseware, Inc. System, method and apparatus for presentation of sensor information to a building control system
US11722365B2 (en) 2014-05-13 2023-08-08 Senseware, Inc. System, method and apparatus for configuring a node in a sensor network
US10149141B1 (en) 2014-05-13 2018-12-04 Senseware, Inc. System, method and apparatus for building operations management
US9800646B1 (en) * 2014-05-13 2017-10-24 Senseware, Inc. Modification of a sensor data management system to enable sensors as a service
US10652767B1 (en) * 2014-05-13 2020-05-12 Senseware, Inc. System, method and apparatus for managing disruption in a sensor network application
US9551594B1 (en) 2014-05-13 2017-01-24 Senseware, Inc. Sensor deployment mechanism at a monitored location
KR102003573B1 (ko) * 2014-05-26 2019-07-25 전자부품연구원 IoT 디바이스 교체 방법
KR102065194B1 (ko) * 2014-05-26 2020-01-13 전자부품연구원 IoT 디바이스 리-페어링 방법
KR101983864B1 (ko) * 2014-05-26 2019-05-30 전자부품연구원 IoT 디바이스 캐싱 방법
EP3149994B1 (en) * 2014-06-02 2019-10-02 Telefonaktiebolaget LM Ericsson (publ) Merging proxy
KR101790934B1 (ko) 2014-06-12 2017-10-26 콘비다 와이어리스, 엘엘씨 콘텍스트 인식 이웃 발견
CN105323186B (zh) * 2014-06-20 2020-04-21 中兴通讯股份有限公司 一种通知消息的负载控制方法和装置
WO2016007813A1 (en) * 2014-07-10 2016-01-14 Convida Wireless, Llc Layered management server delegation
CN105323780A (zh) * 2014-07-18 2016-02-10 中兴通讯股份有限公司 物联网的终端拓扑管理服务方法、装置及系统
EP3170111B1 (en) * 2014-07-18 2021-10-27 Convida Wireless LLC M2m ontology management and semantics interoperability
CN106664514B (zh) * 2014-07-18 2021-02-19 康维达无线有限责任公司 在m2m接口中建立和执行组-组操作的装置和方法
US10009707B2 (en) 2014-07-22 2018-06-26 Convida Wireless, Llc Interworking light weight machine-to-machine protocol with device management protocol
CN105323228B (zh) * 2014-07-30 2019-11-05 中兴通讯股份有限公司 更新资源通告的方法、本地公共业务实体及系统
CN106489253B (zh) * 2014-08-20 2019-10-18 华为技术有限公司 中间节点、基础设施节点及m2m业务消息转发方法
CN106797406B (zh) * 2014-08-21 2021-01-08 诺基亚技术有限公司 使用6LoWPAN头部压缩机制的IPv4通信
CN105406953B (zh) * 2014-09-15 2019-09-06 青岛海尔智能家电科技有限公司 一种聚合通知消息的方法及装置
KR101984413B1 (ko) 2014-09-17 2019-09-03 콘비다 와이어리스, 엘엘씨 서비스 레이어를 통해 제3자 서비스들에 대한 액세스를 가능하게 하는 시스템들 및 방법들
US9894474B2 (en) * 2014-09-18 2018-02-13 Alcatel Lucent ZigBee system management employing a TR-069 enabled CPE proxy
GB2530552B (en) * 2014-09-26 2018-07-25 Telit Tech Cyprus Ltd System and method of controlling operation of connected devices
CN105578444A (zh) * 2014-10-10 2016-05-11 青岛海尔智能家电科技有限公司 一种自动订阅资源的方法和装置
KR102005059B1 (ko) * 2014-10-21 2019-07-30 한국전자통신연구원 홈 네트워크 서비스를 제공하기 위한 장치 및 그 방법
CN105653374B (zh) * 2014-11-12 2020-04-28 华为技术有限公司 分布式事务资源执行的方法、装置和系统
KR20210131436A (ko) * 2014-11-14 2021-11-02 콘비다 와이어리스, 엘엘씨 허가 기반 리소스 및 서비스 발견
JP6435057B2 (ja) * 2014-12-01 2018-12-05 コンヴィーダ ワイヤレス， エルエルシー サービス層における交渉サービスをサポートする方法
US9838258B2 (en) 2014-12-04 2017-12-05 At&T Intellectual Property I, L.P. Network service interface for machine-to-machine applications
US10080120B2 (en) 2014-12-15 2018-09-18 Huawei Technologies Co., Ltd System and method for machine type communication
WO2016111914A1 (en) * 2015-01-05 2016-07-14 Convida Wireless, Llc Machine-to-machine protocol indication and negotiation
WO2016109972A1 (zh) * 2015-01-09 2016-07-14 华为技术有限公司 机器到机器系统中宣告属性的方法、公共服务实体和应用实体
US10405159B2 (en) 2015-01-12 2019-09-03 Telefonaktiebolaget Lm Ericsson (Publ) Methods and apparatus for monitoring and managing resource usage in a communication network
CN104796291B (zh) * 2015-04-27 2018-05-29 清华大学 核心路由区域内路由器转发行为规范的检测方法及系统
CN106302840A (zh) * 2015-05-15 2017-01-04 中兴通讯股份有限公司 位置数据处理方法、装置及系统
WO2016196947A1 (en) * 2015-06-05 2016-12-08 Convida Wireless, Llc Method and appparatus of interworking m2m and iot devices and applications with different service layers
KR20170020290A (ko) * 2015-08-14 2017-02-22 전자부품연구원 사물 인터넷에서의 연관된 트랜잭션 처리 방법, 이를 위한 사물 인터넷 통신 노드, 및 이들을 이용한 사물 인터넷 망
US9900775B2 (en) * 2015-09-02 2018-02-20 International Business Machines Corporation On-device authorization of devices for collaboration and association
US10797935B2 (en) 2015-09-02 2020-10-06 Convida Wireless, Llc Methods and apparatus for enhancing native service layer device management functionality
EP3350962B1 (en) * 2015-09-18 2021-11-03 Telefonaktiebolaget LM Ericsson (PUBL) Management of communication between m2m device and m2m server
US9713112B1 (en) * 2015-09-30 2017-07-18 Sonus Networks, Inc. Communications methods, apparatus and systems for correlating registrations, service requests and calls
US10129852B2 (en) * 2016-06-01 2018-11-13 Lg Electronics Inc. Method for broadcasting to unspecified entity in wireless communication system and device for the same
US10833832B2 (en) 2016-06-22 2020-11-10 Intel Corporation Communication device and a method for full duplex scheduling
US10075373B2 (en) * 2016-08-26 2018-09-11 Viasat, Inc. Methods and apparatus for providing traffic forwarder via dynamic overlay network
US9990830B2 (en) 2016-10-06 2018-06-05 At&T Intellectual Property I, L.P. Spatial telemeter alert reconnaissance system
KR102224379B1 (ko) * 2016-10-07 2021-03-08 콘비다 와이어리스, 엘엘씨 일반적 상호연동 및 확장성을 위한 서비스 계층 리소스 관리
JPWO2018109914A1 (ja) * 2016-12-15 2019-10-24 株式会社日立製作所 サービス提供管理システムおよびサービス提供管理方法
WO2018129956A1 (zh) * 2017-01-13 2018-07-19 京东方科技集团股份有限公司 操作实例资源的方法和装置
US10484151B2 (en) * 2017-03-02 2019-11-19 Qualcomm Incorporated Controlling random-access channel (RACH) retransmissions for wireless communication
US10588168B2 (en) 2017-05-15 2020-03-10 Apple Inc. Peer-to-peer transmission pause indication
DE102017006927A1 (de) * 2017-07-20 2019-01-24 Daimler Ag Kommunikationsnetzwerk
CN109309654B (zh) * 2017-07-28 2022-01-21 京东方科技集团股份有限公司 创建资源的方法及相应的注册方法、服务器和客户端装置
CN109391656B (zh) * 2017-08-09 2021-10-08 中兴通讯股份有限公司 一种设备管理会话的恢复方法、装置、客户端及服务器
CN109560945B (zh) * 2017-09-25 2021-02-12 华为技术有限公司 业务服务质量的检测方法、设备及系统
US10833923B2 (en) 2017-10-26 2020-11-10 Skylo Technologies Inc. Dynamic multiple access for distributed device communication networks with scheduled and unscheduled transmissions
US10469600B2 (en) * 2017-11-14 2019-11-05 Dell Products, L.P. Local Proxy for service discovery
CN108040042B (zh) * 2017-12-05 2020-07-03 重庆邮电大学 一种针对多播情况下CoAP协议的安全方法
CN109905431B (zh) * 2017-12-08 2021-01-26 京东方科技集团股份有限公司 消息处理方法及系统、存储介质、电子设备
US11388262B2 (en) * 2017-12-29 2022-07-12 Telefonaktiebolaget Lm Ericsson (Publ) Compression context setup for data transmission for IOT devices
US10306442B1 (en) * 2018-01-16 2019-05-28 Skylo Technologies Inc. Devices and methods for specialized machine-to-machine communication transmission network modes via edge node capabilities
US11153309B2 (en) 2018-03-13 2021-10-19 At&T Mobility Ii Llc Multifactor authentication for internet-of-things devices
US10708261B2 (en) * 2018-05-07 2020-07-07 Vmware, Inc. Secure gateway onboarding via mobile devices for internet of things device management
US11018930B2 (en) * 2018-05-16 2021-05-25 Vmware Inc. Internet of things gateway onboarding
WO2020085528A1 (ko) * 2018-10-24 2020-04-30 전자부품연구원 구독 만료 관리 방법 및 이를 적용한 m2m 시스템
CN110234096A (zh) * 2019-05-23 2019-09-13 上海易点时空网络有限公司 基于双向确认的数据上报方法及装置
TWI737106B (zh) * 2019-12-31 2021-08-21 啟碁科技股份有限公司 韌體更新方法和韌體更新系統
CN111523860B (zh) * 2020-04-23 2023-05-23 北京思特奇信息技术股份有限公司 一种采用组件化管理农业产品生产过程的方法和系统
CN111817886B (zh) * 2020-06-29 2023-12-26 新华三信息安全技术有限公司 一种获取管理对象数据的方法及设备
US20220141658A1 (en) * 2020-11-05 2022-05-05 Visa International Service Association One-time wireless authentication of an internet-of-things device

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110016379A1 (en) * 2009-07-15 2011-01-20 Cloudscale Inc. System and Methodology for Data Processing Combining Stream Processing and Spreadsheet Computation

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4355842B2 (ja) * 2005-08-11 2009-11-04 ソフトバンクモバイル株式会社 サービス管理システム、通信システム及び音声メールシステム。
US9811849B2 (en) * 2007-09-28 2017-11-07 Great-Circle Technologies, Inc. Contextual execution of automated workflows
EP2245829B1 (en) * 2008-01-18 2016-01-06 InterDigital Patent Holdings, Inc. Method for enabling machine to machine communication
US8407769B2 (en) * 2008-02-22 2013-03-26 Telefonaktiebolaget Lm Ericsson (Publ) Methods and apparatus for wireless device registration
US8737989B2 (en) * 2008-08-29 2014-05-27 Apple Inc. Methods and apparatus for machine-to-machine based communication service classes
CN101477535B (zh) * 2008-12-30 2011-06-08 华为技术有限公司 网页页面的显示方法、请求的处理方法、装置和系统
TWI374637B (en) * 2008-12-31 2012-10-11 Ind Tech Res Inst Information transmission and service integration system and method thereof
JP2010193264A (ja) * 2009-02-19 2010-09-02 Nec Corp ネットワークシステムおよび伝送装置
CN101730104A (zh) * 2009-06-23 2010-06-09 中兴通讯股份有限公司 用户设备接入认证方法、装置及无线局域网接入网络
KR20120099794A (ko) 2009-12-28 2012-09-11 인터디지탈 패튼 홀딩스, 인크 사물 지능 통신 게이트웨이 아키텍쳐
US8942191B2 (en) * 2010-05-03 2015-01-27 Mformation Software Technologies Llc Providing dynamic group subscriptions for M2M device communication
CN102148863A (zh) * 2011-01-27 2011-08-10 华为技术有限公司 一种m2m业务消息传递的方法及装置

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110016379A1 (en) * 2009-07-15 2011-01-20 Cloudscale Inc. System and Methodology for Data Processing Combining Stream Processing and Spreadsheet Computation

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
논문, REST 기반 M2M 플랫폼 기술 연구, 한국산학기술학회 학술대회논문집, 2011.09.

Also Published As

Publication number Publication date
CN103621113A (zh) 2014-03-05
US20170013063A1 (en) 2017-01-12
US20140126581A1 (en) 2014-05-08
TW201742417A (zh) 2017-12-01
JP2014506764A (ja) 2014-03-17
WO2012109531A3 (en) 2012-10-11
CN103621113B (zh) 2017-07-14
TW201249154A (en) 2012-12-01
EP2854423A1 (en) 2015-04-01
US10455024B2 (en) 2019-10-22
US20180248957A1 (en) 2018-08-30
WO2012109531A2 (en) 2012-08-16
HK1192677A1 (en) 2014-08-22
EP2673965B1 (en) 2014-12-10
MY162193A (en) 2017-05-31
TWI610552B (zh) 2018-01-01
CN107529693A (zh) 2018-01-02
KR20140008373A (ko) 2014-01-21
TWI642290B (zh) 2018-11-21
JP2017188958A (ja) 2017-10-12
JP6178446B2 (ja) 2017-08-09
US9426222B2 (en) 2016-08-23
US9986038B2 (en) 2018-05-29
EP2673965A2 (en) 2013-12-18
CN107529693B (zh) 2020-08-21
JP2016158248A (ja) 2016-09-01
JP6659627B2 (ja) 2020-03-04
EP2854423B1 (en) 2019-10-23
JP5894193B2 (ja) 2016-03-23

Similar Documents

Publication Publication Date Title
KR101963466B1 (ko) Ｍ2ｍ(ｍａｃｈｉｎｅ-ｔｏ-ｍａｃｈｉｎｅ) 엔터티를 관리하는 시스템, 방법 및 장치
US10735888B2 (en) Machine-to-machine (M2M) gateway (GW) and method for M2M registration
JP6603341B2 (ja) リソースの公表および公表取消しのためのマシン間（ｍ２ｍ）インタフェース手順
US10972575B2 (en) Method and system for supporting edge computing
JP6456472B2 (ja) 複数のデバイス上での複数のコマンドの実行を可能にすることによるｍ２ｍシステムにおけるサービス層と管理層との間の拡張型動作
WO2018232253A1 (en) Network exposure function
WO2017106619A1 (en) Systems and methods associated with edge computing
KR101975291B1 (ko) 서비스 레이어에서의 리소스 링크 관리

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right