KR20130126229A - Ｍ2Ｍ 응용의 ＳａａＳ모델 지원을 위한 Ｍ2Ｍ 플랫폼에서의 멀티 태넌시 지원 방안 - Google Patents

Abstract

본 명세서는 M2M 응용의 SaaS 모델 지원을 위한 M2M 플랫폼에서의 멀티 태넌시 지원 방안에 관한 것이다.

Description

Ｍ2Ｍ 응용의 ＳａａＳ모델 지원을 위한 Ｍ2Ｍ 플랫폼에서의 멀티 태넌시 지원 방안{A multi-tenancy supporting method in M2M platforms for the SaaS model of M2M applications}

본 발명은 M2M (Machine to Machine Communication) 응용의 SaaS 모델 지원을 위한 M2M 플랫폼에서의 멀티 태넌시 지원 방안 에 관한 것이다.

기존의 M2M 응용은 특정 필요에 의해 사용자가 독자적으로 Area network을 구축하고 M2M 응용을 구현하여 요구사항에 만족하는 시스템을 구성하였다. 조금 더 발전된 형태로 많은 응용들이 공동으로 사용하는 M2M 플랫폼이 등장하면서 좀 더 오픈된 형태로 발전하기 시작했다. 더 나아가 아직은 막 태동하기 시작한 단계인, ASP (Application Service Provider) 형태로 M2M 응용을 원하는 사용자 그룹에 제공가능하다. ASP 형태의 소프트웨어 제공은 인터넷을 통해 응용 서비스를 제공하는 형태로, 이러한 형태는 하나의 사용자 그룹 (tenant, 태넌트)이 하나의 응용 instance를 사용하는 구조로 사용자 그룹이 많아지면 그에 상응하는 응용 instance을 사용자 그룹의 수만큼 새로 생성해야 하기 때문에 확장성이나 자원 효율적인 구조가 되지 못하였다. 여기서 사용자 그룹이란 한 기업이나 조직내의 사용자들을 말하며 SaaS 모델에서는 일반적으로 테넌트 (tenant)라고 불리운다.

기존의 많은 M2M 시스템들은 하나의 응용을 위해 dedicated된 하나의 Area Network이 구축되어 사용되었기 때문에 자원을 공유하지 못해 비효율적이였다. 최근에 플랫폼을 공유하여 제공하는 플랫폼 사업이 활성화되고 있고, ASP 형태로 M2M 응용이 제공될 수 있으나 여전히 하나의 응용 instance를 하나의 고객군 (tenant)이 독점해야 하기 때문에 확장성이나 비용 효율적이지 못한 구조이다.

상술된 문제점을 해결하기 위하여, 본 발명은 M2M 응용들을 비용 효율적인 SaaS 형태로 제공하기 위해 하나의 응용 instance을 여러 고객군(tenant)에서 공유하여 사용할 수 있도록 하는 multi-tenancy feature을 M2M 플랫폼에서 지원하는 방법을 제안하고자 한다.

본 발명의 일 실시예에 의하면 하나의 응용 instance로 다양한 가입자들의 customize된 응용 로직을 지원하는 SaaS 모델을 구현하는 방법론을 제시하여 이러한 기존의 문제점들을 개선하여 하나의 응용으로 다양한 가입자들의 요구사항을 충족시킬 수 있을 뿐만 아니라 가입자들이 공동의 플랫폼이나 시스템 자원을 공유함으로 인해 확장성 있는 구조와 자원 효율성을 동시에 만족시킬 수 있도록 한다.

본 발명에 의하면, ETSI M2M TC에서의 M2M 시스템은 모든 area network을 많은 NSCL (M2M 플랫폼)이나 M2M 응용에서 공동으로 공유하는 오픈 구조를 지향하고 있어 기존의 dedicated 된 M2M 시스템보다는 훨씬 더 자원 효율적인 구조를 채택하고 있다. 그러나 하나의 가입자군 (tenant)마다 하나의 M2M 응용 instance가 실행되어야 하는 일반적인 소프트웨어 실행 모델로 각 가입자군별 customize된 응용을 위해서는 별개의 M2M 응용을 별도로 구현해야 하는 문제점으로 인해 자원 효율면이나 플랫폼의 확장성에서 한계를 보여 왔다. 본 발명은 하나의 응용 instance로 다양한 가입자들의 customize된 응용 로직을 지원하는 SaaS 모델을 구현하는 방법론을 제시하여 이러한 기존의 문제점들을 개선하여 하나의 응용으로 다양한 가입자들의 요구사항을 충족시킬 수 있을 뿐만 아니라 가입자들이 공동의 플랫폼이나 시스템 자원을 공유함으로 인해 확장성 있는 구조와 자원 효율성을 동시에 만족시킬 수 있다.

도 1은 본 명세서의 일 실시예에 의한 <container> 자원의 구조를 보여주는 도면이다.
도 2는 본 명세서의 일 실시예에 의한 contentInstances 자원의 구조 를 보여주는 도면이다.
도 3은 본 발명의 일 실시예에 의한 <contentInstances> 자원의 메타 데이터를 수정하는 절차의 Message 흐름도이다.
도 4는 M2M 플랫폼에서 multi-tenancy을 지원하기 위해, 응용 등록에서부터 특정 응용에 tenant 가입 및 탈퇴시의 contentInstances의 메타 데이터 수정 절차를 포함한 절차 흐름도를 나타낸다.
도 5는 본 명세서의 일 실시예에 의한 <contentInstances> 자원의 메타 데이터 중 TenantID 리스트 값 예제이다.

이하, 본 발명의 일부 실시 예들을 예시적인 도면을 통해 상세하게 설명한다. 각 도면의 구성요소들에 참조부호를 부가함에 있어서, 동일한 구성요소들에 대해서는 비록 다른 도면상에 표시되더라도 가능한 한 동일한 부호를 가지도록 하고 있음에 유의해야 한다. 또한, 본 발명을 설명함에 있어, 관련된 공지 구성 또는 기능에 대한 구체적인 설명이 본 발명의 요지를 흐릴 수 있다고 판단되는 경우에는 그 상세한 설명은 생략한다.

또한, 본 발명의 구성 요소를 설명하는 데 있어서, 제 1, 제 2, A, B, (a), (b) 등의 용어를 사용할 수 있다. 이러한 용어는 그 구성 요소를 다른 구성 요소와 구별하기 위한 것일 뿐, 그 용어에 의해 해당 구성 요소의 본질이나 차례 또는 순서 등이 한정되지 않는다. 어떤 구성 요소가 다른 구성요소에 "연결", "결합" 또는 "접속"된다고 기재된 경우, 그 구성 요소는 그 다른 구성요소에 직접적으로 연결되거나 접속될 수 있지만, 각 구성 요소 사이에 또 다른 구성 요소가 "연결", "결합" 또는 "접속"될 수도 있다고 이해되어야 할 것이다.

본 발명의 실시예들은 사물 통신을 중심으로 설명한다. 사물 통신은 M2M(Machine to Machine communication), MTC(Machine Type Communication), IoT(Internet of Things), 스마트 장치 통신(Smart Device Communication, SDC), 또는 사물 지향 통신(Machine Oriented Communication) 등으로 다양하게 불려질 수 있다. 사물 통신은 사람이 통신 과정에 개입하지 않고 통신이 이루어지는 다양한 통신을 지칭한다. 사물 통신은 지능형 검침(Smart Meter), 전자 보건(e-Health), 통신 가전(Connected Consumer), 도시 자동화(City Automation), 차량 응용(Automotive Application) 등을 포함하는 다양한 분야에 사용될 수 있다.

기존의 M2M 응용은 단독의 요구 사항을 성취하기 위해 독자적인 Area Network를 연결하여 하나의 M2M 플랫폼으로 하나의 시스템을 구축하였다. 최근 들어 더 다양한 응용 요구사항들을 M2M 영역에서 커버하기 시작하면서 Area Networks을 공유하여 다양한 응용들에서 활용 가능한 구조로 바뀌고 있다. 또한 하나의 플랫폼을 공동으로 활용하여 다양한 응용들을 개발하고 이러한 M2M 응용들을 다양한 고객군에서 사용하고자 하는 요구사항들이 많아지고 있다. 네트워크 제공자나 플랫폼 제공자들은 이러한 다양한 M2M 응용들을 위해 자사의 인프라를 대여해주고 사용료를 받는 비즈니스를 시작하였고, 좀 더 효과적인 비즈니스를 위해 M2M 응용을 가입한 누구나 쓸 수 있도록 하는 SaaS (Software As A Service) 모델로의 전환이 대두되고 있다. SaaS 가 기존의 ASP (Application Service Provider)와 구분되는 가장 큰 특징은 하나의 소프트웨어 인스턴스로 여러 사용자 (tenant)에게 커스터마이징 (customizing)된 어플리케이션을 제공해 주는 것으로 이러한 기능 (feature)을 multi-tenancy라고 한다. 본 발명은 M2M 시스템의 가장 상위 레이어에 존재하는 M2M 응용들을 SaaS 모델로 전환하기 위해 가장 중요하게 요구되어지는 멀티태넌시 (Multi-tenancy) 기능을 M2M 플랫폼에서 지원하는 방안을 제시하고자 한다.

ETSI에서 정의한 바에 따르면 M2M 시스템의 high level 구조는 크게 네트워크/응용 도메인과 디바이스/게이트웨이 도메인으로 나누어지고 네트워크 도메인의 M2M Service Capability Layer는 모든 응용에서 필요한 공통 기능들을 제공하는 M2M 플랫폼 영역이다. ETSI의 M2M Service Requirements 문서 (TS 102 689)를 보면 일반적인 요구사항 중 하나로 연결된 오브젝트 수에 대한 scalability 지원이 요구되어 있고 그 요구사항과 관련되어 Annex D에는 시스템 리소스를 최소로 사용할 수 있도록 시스템이 설계되어야 한다고 명시되어 있다. 이러한 확장성이나 비용 효율적인 시스템 요구사항들은 물론 연결된 오브젝트 수의 관점에서도 충족되어야 하지만 지원하는 응용의 갯수나 사용자의 수 등과 관련되어서도 중요한 요구사항이다.

종래의 (상용) M2M 시스템은 하나의 M2M Area Network에 속해 있는 디바이스와 게이트웨어들이 하나의 M2M 응용을 지원하는 dedicated 방식으로 설계되어 확장성에 대한 요구가 상대적으로 적었고 이 때문에 크게 고려 대상이 되지 않았다. ETSI 표준안에서는 다양한 Area Network들을 여러 M2M 응용들에서 공유할 수 있을 뿐만 아니라 플랫폼까지 응용들에서 공유하는 open된 구조를 지향하기 때문에 연결된 수 많은 디바이스들의 수와 그들이 발생하는 데이터의 양, 그리고 다양한 M2M 응용들의 트랜잭션들로 인해 확장성 있고, 동시에 비용 효율적인 구조가 요구되어진다.

ETSI M2M TC의 표준 문서 (TS 102 689)에서 scalability나 자원 효율적인 시스템 설계에 대한 요구사항들이 언급되어 있으나 Functional Architecture 등의 TS 문서에서는 그러한 요구사항들을 만족시킬 수 있는 구체적인 방법들에 대해 전혀 명시하지 않고 있다. 또한 M2M 시스템은 여러 M2M 응용들을 관리할 수 있는 메커니즘을 지원해야 하며 이러한 메커니즘 지원을 위해 등록된 M2M 응용들의 리스트을 유지하고 등록 정보 또한 유지해야 한다고 명시하고 있다. 그러나 좀 더 비용 효율적이고 확장 가능한 구조를 위해서는 다양한 응용들을 관리해야 할 뿐만 아니라 하나의 응용에 가입(등록)한 다양한 고객들까지 관리하여 M2M 플랫폼에서 각 고객들의 요구사항을 customizing할 수 있도록 하는 multi-tenancy 지원이 가능해야 한다.

ETSI M2M TC에서는 M2M 시스템을 Restful 형태의 자원 (resource) 기반으로 규정하고 있다. 하나의 자원은 RESTful 환경에서 유일하게 구분 가능한 엔티티이다. 즉, Restful 구조는 M2M 응용(DA: Device Application, GA: Gateway Application, NA: Network Application)들과 또는 M2M SCL (Service Capability Layer)이 서로 정보를 교환하는 방식이다. ETSI M2M TC에서는 SCL에 위치한 Restful 형태의 리소스 구조를 표준화하고 있다. 하나의 SCL 내에서는 SclBase 자원을 root로 하여 다른 모든 자원들을 계층적인 트리 (tree) 구조로 모델링하고 있다.

본 발명에서는 이러한 자원 구조에서 관련 있는 자원 구조들을 중심으로 상기의 발명 목적을 어떻게 달성하는지를 기술하고자 한다. 우선 Application 자원은 응용에 대한 정보를 저장하고 있으며 응용을 SCL에 등록 (registration)함으로서 생성된다.

도 1은 본 명세서의 일 실시예에 의한 <container> 자원의 구조를 보여주는 도면이다.

도 2는 본 명세서의 일 실시예에 의한 contentInstances 자원의 구조 를 보여주는 도면이다.

Container 자원은 데이터를 담는 매개체로서 응용들과 SCL 들이 데이터를 교환하는데 사용되는 일반적인 (generic) 자원이다. 즉, 하나의 Container 자원은 instances 들을 담는 용기 (container) 자원이다. 계층구조에서 도 1과 같이 하위 리소스로 contentInstances를 가지며 contentInstances 자원은 하나의 container 자원 내 내용 (content) instance들의 집합을 나타낸다. 도 2를 참조하면 contentInstances 자원은 다시 하위 자원으로 여러 개의 contentInstance 자원들을 가진다. ContentInstace 자원은 container내 하나의 데이터 (content)를 나타내는 자원으로 접근 가능한 메타 데이터 (meta-data)를 가진다. 데이터 (content) 예로는 보안 카메라에 찍힌 이미지나 온도 센서에 의해 측정된 온도 값 등이 있다. contentInstances를 조회 (retrieve)하면 자식 자원들에 대한 참조 값을 리턴하는 것이 아니라 contentInstance 자원들의 집합 내 내용들을 리턴한다. 조회시 메타 데이터 값을 filter로 사용할 수 있다. 메타 데이터는 content의 생성 시간, 사이즈, 종류 (type), content를 직접 접근할 수 있는 URI 등을 포함한다. contentInstance의 값은 한번 생성하면 수정할 수 없다. (TS 102 690 150-151쪽 참조)

M2M 시스템에서 SaaS 형의 응용 모델을 지원하기 위해 tenant, 즉 하나의 end-user 그룹 (여러명의 사용자가 속한 하나의 기관이나 조직)들의 특정한 요구사항을 반영하여 multi-tenancy를 구현해야 한다. 우선 Application 자원내에 attributes에 그 응용에 가입한 각 tenant들 (tenant ID 리스트)을 포함해야 한다. (여기서의 응용은 NA (Network Application)만을 고려하기로 한다. 실제로 SaaS 모델이 지원되어야 하는 응용은 네트워크/응용 도메인의 응용에 한정되기 때문이다. 그러나 넓게 적용하면 DA나 GA에의 적용을 배제하진 않는다. DA나 GA에 적용할 때에는 tenant가 조금 다른 엔티티가 될 수 있다. 예를 들면 응용이나 SCL 등 그 응용의 resource를 활용하는 엔티티로 생각할 수 있다.) AttributeName을 편의상 tenantIDs라고 명명하기로 한다. 만약 특정 응용이 SaaS 모델을 지원하지 않을 경우를 고려하여 이 tenantIDs attribute는 선택 (optional) 항목으로 두고 Type은 tenant 가입과 탈퇴가 자유롭기 때문에 RW (read/write)로 둔다. 즉 하나의 응용을 SCL에 등록 (create or register application)할 때 그 응용에 가입한 tenent들의 ID 리스트를 그 application 자원의 tenantIDs attribute로 제공한다. 만약 어떤 tenant가 새로 가입하거나 기존에 가입한 tenant가 탈퇴하는 경우 응용 수정 절차 (update application)을 통해 tenantIDs attribute를 수정한다.

도 3은 본 발명의 일 실시예에 의한 <contentInstances> 자원의 메타 데이터를 수정하는 절차의 Message 흐름도이다.

응용의 SaaS 모델을 지원하기 위해 또 다른 수정이 필요한 자원은 contentInstances이다. ETSI의 M2M TC에서는 각 contentInstance에 메타 데이터가 언급되어 있으나 instance의 group 자원인 contentInstances에도 각 하위 instance의 공통 메타 데이터를 유지할 필요가 존재한다. 유지되는 contentInstances의 메타 데이터 값에 tenant ID 리스트의 추가가 필요하다. 즉 특정한 content는 특정한 tenant에게만 필요한 경우 메타 데이터에서 그 tenant ID가 있는 경우만 그 content를 조회하게 하여 multi-tenancy의 첫 번째 구현 조건인 tenant별 데이터 조회를 가능하게 하는 것이다. 또한 content의 값은 수정 불가능하지만 메타 데이터의 값은 수정 가능해야 한다. 이를 위해 Update meta-data of <contentInstances> 라는 절차를 도 3과 같이 추가해야 한다. Issuer는 주로 NA가 되지만 간혹 다른 SCL이 될 수도 있다.

위의 발명의 구성에서 설명한 특정 자원들의 일부를 수정하여, M2M 응용의 SaaS 모델을 어떻게 지원하는지 구체적인 동작으로 설명해 보기로 한다. 특정 M2M 응용에서 각 tenant의 요구사항이나 로직이 달라서 디바이스 도메인에서 수집한 다른 종류의 데이터를 필요로 하는 경우가 있을 수 있다.

도 4는 M2M 플랫폼에서 multi-tenancy을 지원하기 위해, 응용 등록에서부터 특정 응용에 tenant 가입 및 탈퇴시의 contentInstances의 메타 데이터 수정 절차를 포함한 절차 흐름도를 나타낸다.

도 4의 흐름도를 보면서 설명해 보면, 우선 하나의 응용을 local SCL에 최초 등록할 때는 가입자 (tenant)가 아무도 없는 경우가 대부분이라 tenantIDs attribute을 empty로 비워두게 된다. 하나의 tenant가 위의 응용에 가입하는 경우, 그 응용은 먼저 자신의 tenantIDs attribute에 방금 가입한 tenant의 ID를 추가하기 위해 Update <Application> 절차를 따라 tenantIDs attribute를 일부 수정하게 된다 (TS 102 690 문서의 136쪽 참조). 두 번째로 응용은 그 tenant가 관심 있는 데이터, 즉, 관련된 contentInstances의 메타 데이터의 tenantID 리스트에 가입한 tenant의 ID를 추가하는 절차를 도 3에서 설명하는 바와 같이 hosting SCL에 요청하게 된다. 만약 모든 tenant가 공통적으로 필요한 contentInstances인 경우 메타 데이터의 tenantID 리스트를 "All"로 설정할 수 있도록 하여 추가적인 메타 데이타 수정을 피할 수 있도록 한다. 방금 가입한 tenant가 응용을 실행할 경우 contentInstances의 메타 데이터 내 tenantID 리스트에 자신의 ID를 filter로 하여 추출하면 본인이 원하는 데이터만을 수집하여 본인이 원하는 특정 응용 로직을 실행할 수 있게 된다.

응용 예를 들어, 농촌의 아주 광범위한 영역을 커버하는 area network이 있다고 가정하고 작물들의 작황 상태를 모니터링하는 특정 응용 M (NA)을 SCL 에 등록하는 경우를 생각해 보자. 그 영역을 커버하는 area network에는 여러 디바이스들과 게이트웨어들이 포진해 있고 디바이스의 종류에는 여러 가지 환경 데이터들을 복합적으로 센싱하는 복합 디바이스로부터 특정 factor을 모니터링하는 특수 센싱 디바이스들이 다양하게 전개되어 있다고 가정한다. 처음에 M이 local SCL에 등록 (register application )할 때에는 어떤 가입자도 없다가 이 후 tenant A, B, C가 순서대로 응용 M에 가입한 경우, 응용 M을 수정하는 절차 (update application)를 따라 차례대로 M application 자원의 tenantIDs attribute에 각 ID를 추가하여야 한다. A, B, C 가 모니터링하는 특정 작물의 종류에 따라 예를 들어, 공통적으로 온도, 대기 습도, 조도 등은 다 같이 복합 환경 센서 디바이스로부터 모니터링 되는 데이터라 하고, 특별히, tenant A는 추가하여 이산화탄소(CO2) 농도를 더 추출하여 응용에서 활용하여야 하고, tenant B가 관리하는 작물은 토양 습도를 더 필요로 하며, tenant C는 공통적으로 필요한 데이터만 필요하고 추가적인 데이터는 필요하지 않다고 가정한다.

즉, 정리하면 다음과 같다. M2M 응용의 SaaS 모델 지원을 위한 M2M 플랫폼에서의 멀티 태넌시 지원하기 위하여, 하나의 응용을 로컬 SCL(local SCL)에 최초 등록하는 단계, 제 1 테넌트의 응용 가입 요청 메시지를 수신하는 단계, 상기 제 1 테넌트의 식별 정보를 추가하기 위하여 TenantID 속성(attribute)에 상기 제 1 테넌트의 식별 정보를 추가하는 단계, 및 상기 제 1 테넌트가 추가로 원하는 데이터가 존재하는 경우, 상기 데이터의 contentInstances 메타 데이터의 tenantID 리스트에 상기 가입한 테넌트의 식별 정보를 추가하는 단계를 포함한다.

또한, 상기 응용을 로컬 SCL(local SCL)에 최초 등록하는 단계는 상기 응용에 대한 TenantID 속성을 비워두는 단계를 더 포함하게 된다.

도 5는 본 명세서의 일 실시예에 의한 <contentInstances> 자원의 메타 데이터 중 TenantID 리스트 값 예제이다.

위에서 언급한 다섯 가지의 환경 데이터 각 각이 contentInstances 자원에 저장이 될 경우 온도, 대기 습도, 조도는 모든 tenant가 공통적으로 필요한 데이터이기 때문에 contentInstances의 메타 데이터 중 tenant ID 리스트값으로 "All"이 저장되어야 한다 (도 5 참조). 그리고 이산화탄소 농도의 contentInstances의 메타 데이터로 tenant ID 리스트 값에는 A가 저장되어야 하고 마찬가지로 토양 습도의 contentInstances의 메타 데이터로 tenant ID 리스트값에는 B가 저장되어야 한다. 물론 tenant A, B, C 가 순서대로 응용 M에 가입할 경우, 각 환경 데이터의 contentInstances의 메타 데이터가 도 3에서 설명한 메타 데이터의 수정 절차에 따라 update되어야 한다. 만약 tenant B가 응용 M을 탈퇴할 경우 마찬가지의 메타 데이터 수정 절차를 통해 토양 습도의 contentInstances의 메타 데이터 중 tenant ID 리스트 값에서 B를 삭제하여야 한다.

위에서 설명한 예에서 보듯이 응용 M이 실행되어 서비스되는 경우 각 각의 tenant가 요구하는 데이터를 메타 데이터의 tenant ID 리스트를 filter 값으로 하여 필요한 환경 데이터를 추출하여 M 응용의 instance에 필요한 로직에서 활용 가능하기 때문에 각 tenant별 특별한 응용 로직을 실행하여 multi-tenancy를 구현할 수 있다.

ETSI M2M TC에서의 M2M 시스템은 모든 area network을 많은 NSCL (M2M 플랫폼)이나 M2M 응용에서 공동으로 공유하는 오픈 구조를 지향하고 있어 기존의 dedicated 된 M2M 시스템보다는 훨씬 더 자원 효율적인 구조를 채택하고 있다. 그러나 하나의 가입자군 (tenant)마다 하나의 M2M 응용 instance가 실행되어야 하는 일반적인 소프트웨어 실행 모델로 각 가입자군별 customize된 응용을 위해서는 별개의 M2M 응용을 별도로 구현해야 하는 문제점으로 인해 자원 효율면이나 플랫폼의 확장성에서 한계를 보여 왔다. 본 발명은 하나의 응용 instance로 다양한 가입자들의 customize된 응용 로직을 지원하는 SaaS 모델을 구현하는 방법론을 제시하여 이러한 기존의 문제점들을 개선하여 하나의 응용으로 다양한 가입자들의 요구사항을 충족시킬 수 있을 뿐만 아니라 가입자들이 공동의 플랫폼이나 시스템 자원을 공유함으로 인해 확장성 있는 구조와 자원 효율성을 동시에 만족시킬 수 있다.

이상의 설명은 본 발명의 기술 사상을 예시적으로 설명한 것에 불과한 것으로서, 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자라면 본 발명의 본질적인 특성에서 벗어나지 않는 범위에서 다양한 수정 및 변형이 가능할 것이다. 따라서, 본 발명에 개시된 실시 예들은 본 발명의 기술 사상을 한정하기 위한 것이 아니라 설명하기 위한 것이고, 이러한 실시 예에 의하여 본 발명의 기술 사상의 범위가 한정되는 것은 아니다. 본 발명의 보호 범위는 아래의 청구범위에 의하여 해석되어야 하며, 그와 동등한 범위 내에 있는 모든 기술 사상은 본 발명의 권리범위에 포함되는 것으로 해석되어야 할 것이다.

Claims (2)

1. 하나의 응용을 로컬 SCL(local SCL)에 최초 등록하는 단계;
   제 1 테넌트의 응용 가입 요청 메시지를 수신하는 단계;
   상기 제 1 테넌트의 식별 정보를 추가하기 위하여 TenantID 속성(attribute)에 상기 제 1 테넌트의 식별 정보를 추가하는 단계; 및
   상기 제 1 테넌트가 추가로 원하는 데이터가 존재하는 경우, 상기 데이터의 contentInstances 메타 데이터의 tenantID 리스트에 상기 가입한 테넌트의 식별 정보를 추가하는 단계를 포함하는, M2M 응용의 SaaS 모델 지원을 위한 M2M 플랫폼에서의 멀티 태넌시 지원하는 방법.
   
2. 제 1항에 있어서,
   상기 응용을 로컬 SCL(local SCL)에 최초 등록하는 단계는
   상기 응용에 대한 TenantID 속성을 비워두는 단계를 더 포함하는, M2M 응용의 SaaS 모델 지원을 위한 M2M 플랫폼에서의 멀티 태넌시 지원하는 방법.
   
   

Images