KR102140636B1

KR102140636B1 - Nfv를 통한 풀 기반 m2m 서비스 계층 구축

Info

Publication number: KR102140636B1
Application number: KR1020187032060A
Authority: KR
Inventors: 수 리; 꾸앙 리; 로꼬 디 지롤라모; 비노드 쿠마르 초이; 샤밈 아크바르 라만; 주오 첸; 총강 왕
Original assignee: 콘비다 와이어리스, 엘엘씨
Priority date: 2016-04-05
Filing date: 2017-04-05
Publication date: 2020-08-04
Also published as: US20200326989A1; CN109074283A; EP3440546A1; JP2019514118A; KR20180132826A; WO2017176877A1

Abstract

본 명세서에서는, M2M/IoT 네트워크들에 대한 기존의 접근 방식들이 네트워크 기능 가상화(NFV)를 실현하지 못한다는 것을 알 것이다. 특히, 기존의 M2M 서비스 계층들(예를 들어, oneM2M)은 NFV 실행들에 따라 구축, 관리 또는 운영되지 않는다. 예시적인 실시예에서, M2M 장치는 공통 서비스 기능들이 서로 함께 풀링될 수 있도록 다양한 공통 서비스 엔티티들에게 다양한 역할들을 할당한다. 이러한 역할들은 공통 서비스 엔티티들 간에 이전되어 풀들이 효율적으로 관리되고 제어되도록 할 수 있다. 또한, 풀 멤버들은 하나 이상의 풀에서 나가고 이에 합류할 수 있다.

Description

NFV를 통한 풀 기반 M2M 서비스 계층 구축

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

본 출원은 2016년 4월 5일자로 출원된 미국 가특허 출원 제62/318,401호에 대한 우선권 이득을 주장하며, 그 개시내용은 전체가 참조로 포함된다.

일반적으로, 네트워크 기능 가상화(Network Functions Virtualization: NFV)는 진화하는 표준 IT 가상화 기술을 통해 네트워크 운영자들이 네트워크들을 설계하는 방법을 변환하는 것을 목표로 한다. NFV는 데이터 센터들, 네트워크 노드들 및 최종 사용자 구내에 위치할 수 있는 산업 표준의 대용량 서버들, 스위치들 및 저장소에 다양한 유형들의 네트워크 장비를 통합할 수 있다. 도 1은 전형적인(가상화되지 않은) 네트워크 예와 비교한 NFV의 예를 보여준다. 일반적으로, NFV는 다양한 산업 표준 서버 하드웨어 상에서 실행될 수 있고, 새로운 장비를 설치할 필요 없이 필요에 따라 네트워크의 다양한 위치들로 이동하거나 그러한 위치들에서 인스턴스화될 수 있는 소프트웨어에서의 네트워크 기능들의 구현을 수반한다.

전통적으로, 가상화되지 않은 네트워크들에서, 네트워크 기능들(NF들)은 일반적으로 네트워크 노드들 또는 네트워크 요소들로 지칭될 수 있는 벤더 특정 소프트웨어 및 하드웨어의 조합으로 구현된다. NFV에서, NF들은 상세히 후술하는 가상화 기술을 통해 실현될 수 있다. 일반적으로, NFV는 NF들의 구현을 가상화된 네트워크 기능들(VNF들)이라고 하는 소프트웨어 전용 인스턴스들로 고려한다. VNF는 동등한 네트워크 기능과 동일한 기능적 동작 및 인터페이스들을 제공할 수 있지만 예를 들어 가상 기계(VM) 위에 소프트웨어 인스턴스로 배포될 수 있다.

VNF들은 NFV 인프라스트럭처(예를 들어, 물리적 컴퓨팅 리소스들, 네트워크 리소스들 및 저장 리소스들)를 통해 실행된다. 도 2는 다양한 NF들이 복수의 가상 기계들(VM들) 상에 배포되고, VM들이 하이퍼바이저 위에서 실행되는 NFV의 구현예를 보여준다. 하이퍼바이저는 복수의 VM들이 단일 하드웨어 인프라스트럭처를 공유할 수 있게 하는 프로그램일 수 있는 VM 관리자일 수 있다. 예를 들어, 주어진 하이퍼바이저는 기본의 단일 물리적 기계를 복수의 VM들로 추상화하는데 도움이 될 수 있다. 따라서, NFV는 소프트웨어를 하드웨어로부터 분리하고, 네트워크 기능들을 유연하게 배포하며 일반적으로 동적 동작들을 용이하게 하는 것을 도울 수 있다.

하드웨어로부터 소프트웨어를 분리하는 것과 관련하여, 네트워크 요소가 더 이상 통합된 하드웨어 및 소프트웨어 엔티티들의 집합이 아니기 때문에, 하드웨어 및 소프트웨어의 진화는 서로 독립적일 수 있다. 이러한 독립성은 소프트웨어가 하드웨어와 별도로 진행될 수 있게 하며, 그 반대의 경우도 가능한다. 또한, 예를 들어, 하드웨어로부터 소프트웨어를 분리하는 것은 인프라스트럭처 리소스들(예를 들어, 물리적 컴퓨팅 및 저장 리소스들)을 재할당하고 공유하는 것을 돕는다. 따라서, 하드웨어와 소프트웨어는 다양한 시점들에서 상이한 기능들을 수행할 수 있다. 추가 예로서, 네트워크 기능의 기능성을 인스턴스화 가능한 소프트웨어 구성요소들로 분리하는 것은, 예를 들어 네트워크 운영자가 용량을 제공해야 하는 실제 트래픽에 따라, 보다 동적인 방식으로 그리고 보다 미세한 입도로 실제 VNF 성능을 스케일링하는 더 큰 유연성을 제공한다.

따라서, 네트워크 기능 가상화(NFV)는 네트워크 운영자들(NO들)이 직면한 적어도 2가지 문제들, 즉 1) 수익 성장 기대치들과 일치하는 비용들을 가져오는 것, 및 2) 서비스 속도의 향상을 명시적인 목표로 한다. NFV는 과거의 네트워크 접근 방식들에 비해 리소스들을 보다 효율적으로 이용하고 운영 비용(OpEX) 및 자본 비용(CapEX)의 절감을 달성할 수 있다. 예를 들어, NO들은 엔지니어들을 각각의 사이트에 전송할 필요 없이 네트워크 기능들을 배포할 수 있다. 한편, NFV는 예를 들어 기존의 기능별 네트워크 기기들을 이용하는 대신에 임의의 산업 표준 서버 하드웨어 상의 소프트웨어를 통해 서비스들을 제공할 수 있게 함으로써 혁신의 지원을 도울 수 있다. NFV 기술들은 예를 들어, NO들이 다양한 변화하는 요구들을 해결하기 위해 상이한 서비스들을 신속하게 (가상화를 통해) 확장 또는 축소할 수 있기 때문에 네트워크 민첩성, 프로그래밍 가능성 및 유연성을 달성하는데 도움이 될 수 있다. NFV는 시장 출시 기간을 단축할 수 있다. 예를 들어, NO들은 변화하는 영업 요구사항들을 지원하고, 새로운 시장 기회를 포착하며, 새로운 서비스들의 투자 수익을 개선하기 위해 새로운 네트워킹 서비스들을 배포하는 시간을 줄일 수 있다. 또한, NO들은 새로운 서비스들을 출시할 때 발생할 수 있는 위험들을 낮추고, 제공자들이 서비스들을 쉽게 테스트하고 발전시켜 고객들의 요구를 가장 잘 충족시키는 서비스를 결정할 수 있게 한다. 또한, NFV를 통해, 서비스 제공자(SP)는 하드웨어 및 소프트웨어 장애들에 대한 적합한 수준의 복원력을 향상시키고 보장할 수 있다.

이제 시스템 구현들로 돌아가서, VNF들의 이용은 제공된 서비스들의 신뢰성에 추가적인 도전을 제기할 수 있다. 예를 들어, VNF 인스턴스는 일반적으로 그 호스트(예를 들어, 범용 서버)에 내장된 신뢰성 메커니즘들을 가지고 있지 않는다. 그 결과, 하이퍼바이저들, 가상 기계들, VNF 인스턴스, 하드웨어 장애 등을 포함하는 다양한 수준들의 소프트웨어 장애들과 같은 위험 요인들이 있을 수 있다.

보다 높은 신뢰성을 달성하기 위해, VNF 풀 아키텍처로 지칭될 수 있는 아키텍처는 그 기능을 제공하기 위해 풀로 그룹화된 동일한 기능을 갖는 복수의 VNF 인스턴스들을 포함할 수 있다. 개념적으로, 풀 관리자(PM)는 특정 유형의 NF에 대해 VNF 풀을 관리할 수 있다. 예를 들어, PM은 어떤 VNF 인스턴스들(풀 멤버들)이 활성 또는 대기 중인지를 선택할 수 있으며, PM은 서비스 제어 엔티티(SCE)와 상호작용할 수 있다. SCE는 네트워크 기능 세트(예를 들어, VNF들)를 결합하고 조율하여 다양한 네트워크 서비스들을 구축하는 엔티티를 지칭한다. VNF 풀 이용의 이점은 중복 관리와 같은 신뢰성 메커니즘들이 VNF 풀에 의해 달성되므로, SCE와 그 VNF 인스턴스들의 외부 사용자들에게 투명하다는 것이다.

도 3을 참조하면, 예시적인 VNF 풀 아키텍처(300)가 도시되어 있다. VNF 풀 아키텍처(300)는 네트워크 서비스들을 구축하기 위해 네트워크 기능들을 결합 및 조율하는 방법을 결정하는 서비스 제공자의 논리 엔티티인 예시적인 서비스 제어 엔티티(302)를 포함한다. VNF 풀 아키텍처(300)는 제1 예의 VNF(네트워크 기능 'A'에 대한 VNF A) 및 제2 예의 VNF(네트워크 기능 'B'에 대한 VNF B)를 추가로 포함한다. 논리 엔티티일 수 있는 주어진 VNF는 동등한 네트워크 기능과 동일한 특정 기능적 동작 및 인터페이스들을 제공할 수 있다. 각각의 VNF는 소프트웨어 인스턴스로 구현될 수 있다. 또한, 도시된 예에 따르면, VNF A와 VNF B는 서로 비교할 때 상이한 기능들을 가질 수 있다. 도시된 바와 같이, VNF A는 풀(VNF-A 풀)을 포함하고, VNF B는 풀(VNF-B 풀)을 포함한다. 일부 사례들에서, VNF의 각각의 유형에는 풀 멤버들이 VNF로 구현된 소프트웨어 인스턴스들인 대응 풀이 있다. 예를 들어, 도시된 바와 같이, VNF-A 풀은 VNF-A(예를 들어, VNF-A#1 등)를 구현하는 다양한 인스턴스들을 포함하고, VNF-B 풀은 VNF-B(VNF-B#1 등)를 구현하는 다양한 인스턴스들을 포함한다. VNF 풀 관리자는 VNF 풀을 관리하는 엔티티일 수 있다. 관리에는 풀 멤버 호출 및 스케줄링(후술함)이 또한 포함될 수 있다. 관리는 SCE(302)와 상호작용하여 주어진 네트워크 기능을 제공하는 것을 또한 포함할 수 있다. 도시된 바와 같이, 예로서, 제1 PM(306a)은 VNF 풀(304a)(VNF A에 대응함)을 관리하고, 제2 PM(306b)은 VNF 풀(304b)(VNF B에 대응함)을 관리한다. 풀 멤버는 대응 VNF 풀에 합류하고 PM이 관리하는 물리적 NF 인스턴스를 지칭할 수 있다. 예로서, 풀 멤버는 CSE 상에서 호스팅되거나 실행되는 CSF 또는 서비스 능력 소프트웨어 인스턴스일 수 있다. 추가 예로서, 도 3에 도시된 바와 같이, VNF-A 및 VNF-B를 구현하는 소프트웨어 인스턴스들은 각각 VNF-A 풀 및 VNF-B 풀의 풀 멤버들이다.

이제 데이터 센터들 및 클라우드 컴퓨팅에 일반적으로 돌아가면, 가상화 기술은 흔히 다른 개념들 및 주제들, 특히 데이터 센터들 및 클라우드 컴퓨팅에 관련된다. 일반적으로, 데이터 센터는 컴퓨터 시스템들과 통신 및 저장 시스템들과 같은 관련 구성요소들을 수용하는데 이용되는 시설이다. 데이터 센터들에는 일반적으로 중복 또는 백업 전원들, 중복 데이터 통신 접속들, 환경 제어들(예를 들어, 공기 조절, 화재 진압) 및 다양한 보안 디바이스들이 포함된다. 데이터 센터들에 비해, 클라우드 컴퓨팅은 최소한의 관리 노력 또는 서비스 제공자와의 상호작용을 통해 신속하게 프로비저닝 및 릴리스할 수 있는 구성가능한 컴퓨팅 리소스들(예를 들어, 네트워크들, 서버들, 저장소, 애플리케이션들 및 서비스들)의 공유 풀에 편재하고 편리한 요구형 네트워크 액세스를 가능하게 하는 모델이다. 클라우드 컴퓨팅은 흔히 다음과 같은 특징들, 즉 1) 주문형 셀프 서비스, 2) 광범위한 네트워크 액세스, 3) 리소스 풀링, 4) 빠른 신축성, 및 5) 측정된 서비스를 갖는다. 주요 서비스 모델들은 SaaS(Software as a Service), PaaS(Platform as a Service), IaaS(Infrastructure as a Service) 등을 포함한다.

전술한 바와 같이, 두 유형들의 컴퓨팅 시스템들(데이터 센터들 및 클라우드 컴퓨팅)은 물리적 유닛으로서 데이터를 저장할 수 있고, 데이터 센터만이 서버들 및 다른 장비를 저장한다. 이와 같이, 클라우드 서비스 제공자들(예를 들어, 구글, 아마존 등)은 흔히 데이터 센터들을 이용하여 클라우드 서비스들 및 클라우드 기반 리소스들을 보관한다. 클라우드와 데이터 센터 간의 차이점은 클라우드가 (사설 클라우드들이 구내(on-premise) 또는 구외(off-premise)에 배포될 수 있다고 제안되었지만) 일반적으로 인터넷 상의 구외 컴퓨팅 형태인 반면, 조직이 흔히 그 로컬 네트워크 내에 구내 데이터 센터를 갖는다는 점이다. 예를 들어, 회사에서 제3자(예를 들어, 구글, 아마존 등)가 제공하는 클라우드 서비스들을 추구하는 경우, 이러한 서비스들은 제3자가 구축한 데이터 센터들에서 실행되는 서비스 인스턴스들에 의해 프로비저닝된다(이러한 경우를 구외 서비스 프로비저닝이라고 지칭한다). 따라서, 회사는 "사용 시간당 지불(pay-as-you-go)", 유연성 및 확장성과 같은 혜택들을 통해 서비스들을 완전히 이용할 수 있다. 이와는 대조적으로 회사는 또한 자체 데이터 센터를 구입하여 로컬로 이를 실행하는 것을 선택할 수 있다. 즉, 클라우드 컴퓨팅은 서비스 프로비저닝의 한 형태로 생각될 수 있으며, 데이터 센터들은 클라우드 기반 서비스들을 실현하는데 이용될 수 있는 물리적 시설을 지칭할 수 있다. 현재, 클라우드 서비스들은 대개 모든 업데이트들 및 지속적인 유지 관리를 수행하는 제3자 클라우드 제공자들에게 아웃소싱되며, 회사들은 흔히 일반적으로 사내 IT 부서에서 운영하는 자체 데이터 센터들에 또한 투자하기도 한다. 데이터 센터들은 회사가 요구에 따라 그 데이터 센터 인프라스트럭처를 투자할 수 있는 경우가 아니면 서비스 확장성 또는 유연성 특징들을 갖지 않는다.

클라우드 컴퓨팅 패러다임은 초기 반복들에 비해 상이한 요구들에 기반한 더 많은 변형들을 포함하도록 진화하였다. 예를 들어, 현재 최종 사용자들과 영업들은 통신 산업에서 과거의 요구사항들에 비해 사용자 경험을 향상시키기 위해 더 많은 것을 요구하고 있다. 핵심 변환은 ETSI에 의해 초기화된 MEC(Mobile-Edge Computing)라고 하는 클라우드 컴퓨팅의 개념들을 적용하기 위해 (코어 네트워크의 서비스들을 프로비저닝하는 대신에) 네트워크 에지에서 직접 서비스를 실행하고 제공하는 능력에 있었다. 일부 사례들에서, MEC는 모바일 네트워크의 에지에서 실행되고 전통적인 중앙집중식 클라우드 배포로는 달성될 수 없는 특정 작업들(예를 들어, 제어 기능들)을 수행하는 클라우드 서버(예를 들어, M2M 게이트웨이)로 볼 수 있다. 도 4는 MEC의 예를 도시한다. MEC는 다양한 특징들, 예를 들어 1) 구내 컴퓨팅, 2) 근접성, 3) 낮은 대기시간, 및 4) 위치 인식을 포함할 수 있다.

가상화는 클라우드 컴퓨팅을 실현하기 위한 핵심 가능화 기술이다. 가상화 기술들은 상이한 범주들로 분류될 수 있다. 예를 들어, 컴퓨팅 가상화는 사용자의 요구에 따라 물리적 컴퓨팅 및 저장 리소스들(예를 들어, 서버 팜)을 가상 기계들로 가상화하는 방법에 중점을 둔 범주이다. 네트워크 가상화는 물리적 네트워크 기재를 복수의 가상 네트워크들로 분할하는 방법 또는 복수의 데이터 센터 네트워크들에 걸쳐 네트워크를 확장하는 방법에 중점을 둔 범주이다. 예로서, 임차인이 사설 가상화 네트워크를 구축해야 하는 경우, 네트워크 가상화는 물리적 기재 네트워크 인프라스트럭처 위에 이 네트워크의 가상 링크들을 구축하는 것을 담당할 수 있다. 특히, 이 가상화된 네트워크에서의 노드들 또는 VM들이 (예를 들어, 데이터 센터들을 거쳐) 상이한 장소들로 이전하거나 이동해야 하는 경우, 네트워크 가상화는 기본의 기재 네트워크(예를 들어, 물리적 링크들 또는 경로들)가 어떻게 변경되었는지에 관계 없이 가상화된 네트워크의 유지 관리를 담당한다. NFV는 소프트웨어 기기들을 이용하여 독점 하드웨어 네트워크 기기들을 대체하는 방법에 중점을 둘 수 있는 다른 범주의 가상화로 고려될 수 있다. 특히, NFV는 전술한 바와 같이 VNF 인스턴스들을 VM들 위에 배포할 수 있으므로 컴퓨팅 가상화와 관련이 있다. 한편, NFV는 물리적 네트워크 인프라스트럭처에 적용할 것인지 또는 네트워킹 가상화를 통해 가상화 네트워크에 적용할 것인지 여부에 관계 없이 더 나은 네트워크 서비스들을 제공하기 위해 네트워크를 보다 민첩하고, 프로그래밍 가능하고, 유연하며, 확장가능하게 만드는데 중점을 둔다.

이제 도 5를 참조하면, 예시적인 M2M 시스템 아키텍처(500)가 도시되어 있다. 도시된 바와 같이, M2M 시스템(500)은 M2M 최종 디바이스들(504)과 M2M 게이트웨이들(GW들)(506) 사이의 접속을 제공하는 M2M 영역 네트워크(502)를 포함한다. M2M 영역 네트워크들의 예들은 IEEE 802.15, 지그비, 블루투스 등과 같은 기술들을 기반으로 하는 개인 영역 네트워크들을 포함한다. M2M 최종 디바이스들(504)은 M2M GW(506)와 통신할 수 있으며, M2M GW(506) 및 액세스 네트워크 또는 코어 네트워크(512)를 통해, 예를 들어 인터넷 상에 있는 외부 네트워크들 및 애플리케이션 시스템들(510)과의 상호작용들 및/또는 인터페이싱을 가능하게 할 수 있는 M2M 서버(508)와 통신할 수 있다. 많은 M2M 디바이스들(504)은 예를 들어 감각 정보(예를 들어, 습도, 온도 등)를 보고하거나 제어기들(예를 들어, 조명 스위치)로서 기능하는 것과 같은 서비스들을 제공하는 리소스-한정 엔티티들이다. M2M 디바이스들(504)은 또한 리소스-풍부 기기 유형들(예를 들어, 전원들을 갖춘 가전 기기들, 셀폰들, 차량들, 기타 산업 장비 등)일 수 있다.

이제 도 6을 참조하면, 서비스 계층(602)이 전형적인 애플리케이션 프로토콜 계층(604) 위에 있는 예시적인 프로토콜 스택(600)이 도시되어 있다. 서비스 계층(602)은 애플리케이션들(601) 또는 다른 서비스 계층에 부가 가치 서비스들(예를 들어, 디바이스 관리, 데이터 관리 등)을 제공할 수 있다. 따라서, 서비스 계층은 흔히 '미들웨어' 서비스들로 분류된다.

서비스 계층들과 관련하여, 배경기술로서, M2M/IoT 노드들을 목표로 하는 서비스 계층은 M2M/IoT 서비스 계층이라고 지칭될 수 있다. 네트워크 내의 M2M/IoT 서비스 계층 인스턴스의 예시적인 배포가 도 7에 도시되어 있다. 도시된 예에서, 서비스 계층 인스턴스(702)는 서비스 계층을 실현한 것이다. 복수의 서비스 계층 인스턴스들은 네트워크 애플리케이션들, 디바이스 애플리케이션들 및 네트워크 노드들 자체에 부가 가치 서비스들을 제공하기 위해 다양한 네트워크 노드들(예를 들어, 게이트웨이들 및 서버들) 상에 배포될 수 있다. 산업 표준 기관들(예를 들어, oneM2M)은 M2M/IoT 유형들의 디바이스들 및 애플리케이션들을 기존의 네트워크들에 통합하는 것과 관련된 다양한 문제들을 해결하기 위해 M2M/IoT 서비스 계층들을 개발해왔다. M2M 서비스 계층은 서비스 계층에 의해 지원되는 M2M 지향 서비스 능력들의 집합에 대한 애플리케이션 및 디바이스 액세스를 제공할 수 있다. 이러한 능력들의 예들은 보안, 과금, 데이터 관리, 디바이스 관리, 발견, 프로비저닝 및 접속 관리를 포함한다. 이러한 능력들은 애플리케이션 프로그램 인터페이스들(API들)을 통해 애플리케이션들에서 이용가능하게 될 수 있으며, 이는 M2M 서비스 계층에 의해 정의된 메시지 프리미티브들을 이용할 수 있다.

이제 oneM2M으로 돌아가면, 배경기술로서, oneM2M의 목적은 하드웨어 장치들 및 소프트웨어 모듈들 내에 쉽게 내장될 수 있는 공통 서비스 계층에 대한 요구를 해결하는 기술 사양들을 개발하여 관련 분야에서 매우 다양한 디바이스들을 지원하는 것이다. oneM2M 공통 서비스 계층은 도 8에서의 예시적인 oneM2M 아키텍처(800)에 의해 도시된 바와 같이 공통 서비스 기능들(CSF들)(서비스 능력들)의 세트를 지원한다. 하나 이상의 특정한 유형의 CSF들의 세트의 인스턴스화는 상이한 유형들의 네트워크 노드들(예를 들어, 인프라스트럭처 노드, 중간 노드 및 애플리케이션 특정 노드) 상에서 호스팅될 수 있는 공통 서비스 엔티티(CSE)라고 지칭된다. CSE들은 oneM2M 기능적 아키텍처에서 정의된 바와 같이 각각 IN-CSE, MN-CSE 및 ASN-CSE라고 한다.

표준 기관 oneM2M은 도 9에 도시된 oneM2M ROA RESTful 아키텍처 내에서 상이한 리소스들이 정의된다는 점에서 리소스 지향 아키텍처(ROA) 설계 원리에 따라 서비스 계층을 개발하고 있었다. 리소스는 아키텍처 내에서 고유하게 주소지정가능한 요소이다. 리소스는 생성, 검색, 업데이트 및 삭제와 같은 RESTful 방법들을 통해 조작될 수 있다. 리소스들은 URI(Uniform Resource Identifier)들을 이용하여 주소지정가능하다. 리소스는 자식 리소스(들) 및 속성(들)을 포함할 수 있다.

최근에, oneM2M은 RESTful 기반이 아닌 레거시 배포들을 고려하기 위해 M2M 서비스 구성요소 아키텍처(도 10에 도시됨)를 개발하기 시작하였다. 이 아키텍처는 주로 CSE가 서비스 구성요소 세트로 여겨지는 인프라스트럭처 도메인에 적합하다. 도 10에 도시된 아키텍처는 도 9에 도시된 기존의 서비스 계층 아키텍처를 재이용하지만, 서비스 계층 내에서 다양한 M2M 서비스들을 포함하고, 복수의 서비스들이 서비스 구성요소들로 그룹화될 수 있다. 기존의 기준점들에 추가하여, 도 10에 도시된 아키텍처는 서비스간 기준점(Msc)을 도입한다. (Msc 기준점을 지나는) M2M 서비스 구성요소들 간의 통신은 서비스 지향 아키텍처(SOA) 기반 소프트웨어 시스템들을 구축하는데 가장 널리 이용되는 기술일 수 있는 웹 서비스 접근 방식을 이용한다.

전술한 바와 같이, NFV는 보다 나은 네트워크 서비스들을 제공하기 위한 다양한 이점들을 갖는다. 그러나, M2M/IoT 네트워크들에 대한 기존의 접근 방식들은 NFV를 실현하지 못한다.

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

본 명세서에서는, M2M/IoT 네트워크들에 대한 기존의 접근 방식들이 네트워크 기능 가상화(NFV)를 실현하지 못한다는 것을 알 것이다. 특히, 기존의 M2M 서비스 계층들(예를 들어, oneM2M)은 NFV 실행들에 따라 구축, 관리 또는 운영되지 않는다. 따라서, NFV의 이점들은 기존의 서비스 계층에서 실현되지 않는다.

예시적인 실시예에서, M2M 노드는 복수의 공통 서비스 엔티티들에게 요청을 전송한다. 이 요청은 각각의 공통 서비스 엔티티(CSE)의 현재 용량 및 각각의 CSE가 공통 서비스 기능(CSF) 풀 제어기(CPC) 또는 CSF 풀 관리자(CPM)가 되려고 하는지 여부를 질의할 수 있다. 이 요청에 응답하여, 노드는 복수의 공통 서비스 엔티티들로부터 복수의 응답들을 수신하고, 각각의 응답은 각각의 CSE가 CPC 또는 CPM일 수 있는지 여부에 관련된 정보를 포함한다. 서비스 제공자일 수 있는 노드는 각각의 응답으로부터의 정보를 평가하여 복수의 공통 서비스 엔티티들로부터 적어도 하나의 CPC 및 적어도 하나의 CPM을 선택한다. 이 노드는 적어도 하나의 CPC에 대한 역할 프로파일을 생성하며, 역할 프로파일은 CPC의 가상 기계에 대한 최소 성능 요구사항, CPC의 가상 기계에 대한 선호 성능 시간, 역할 이전 전략 및 역할 소프트웨어 업데이트 스케줄 중 적어도 하나를 포함한다. 노드는 유사하게 CPM에 대한 역할 프로파일을 생성할 수 있다. 각각의 역할 프로파일들은 CPM가 되도록 선택된 CSE 및 CPC가 되도록 선택된 CSE에게 전송될 수 있다. 노드는 또한 각각의 소프트웨어 패키지를 CPM가 되도록 선택된 CSE 및 CPC가 되도록 선택된 CSE에 배포할 수 있으며, 각각의 패키지는 각각의 CSE가 그 자신을 CPC 또는 CPM이 되도록 구성할 수 있게 한다. 다른 예에서, 노드는 CPM이 되도록 선택된 CSE 및 CPC가 되도록 선택된 CSE에게 각각의 표시를 전송할 수 있으며, 각각의 표시는 각각의 CSE가 그 자신을 CPC 또는 CPM이 되도록 구성할 수 있게 한다.

다른 예시적인 실시예에서, 풀은 풀 멤버들이 풀에 합류하고 풀로부터 삭제될 수 있도록 CPM에 의해 관리된다. 풀 멤버들은 상이한 공통 서비스 엔티티들 상에서 실행되는 CSF 소프트웨어 인스턴스들일 수 있다. 예를 들어, M2M 노드는 공통 서비스 기능(CSF) 풀 제어기(CPC)로부터 통지를 수신할 수 있다. 이 통지는 공통 서비스 엔티티(CSE)의 하나 이상의 CSF 인스턴스가 노드에 의해 관리되는 풀에 합류하려고 신청하고 있음을 나타낼 수 있다. 하나 이상의 CSF 인스턴스가 풀에 합류하도록 승인되면, 노드는 향후 이용을 위해 하나 이상의 CSF 인스턴스를 인벤토리 리스트에 추가할 수 있다. 노드는 CSE에게 메시지를 전송할 수 있으며, 이 메시지는 하나 이상의 CSF 인스턴스가 노드에 의해 관리되고 있음을 나타낼 수 있다. CSE에게 전송된 메시지에 응답하여, 노드는 CSE로부터 확인응답 메시지를 수신할 수 있으며, 이 확인응답 메시지는 CSE와 연관된 성능 데이터를 포함한다. 노드는, 노드가 서비스 계층 요청을 처리하기 위해 하나 이상의 CSF 인스턴스를 할당 또는 호출하려고 할 때 성능 데이터가 참조될 수 있도록, 인벤토리 리스트를 업데이트하여 CSE와 연관된 성능 데이터를 포함하게 할 수 있다. 또한, 일 예에서, 노드는 CSE에게 삭제 통지를 전송할 수 있다. 이 삭제 통지는 하나 이상의 CSF 인스턴스가 풀로부터 삭제되고 있음을 나타낼 수 있다. 이 삭제 통지는 CSE의 하나 이상의 이력 성능 통계치에 기반하여 전송될 수 있다. 노드는 CSE로부터 삭제 확인응답을 수신할 수 있으며, 이 삭제 확인응답은 하나 이상의 CSF 인스턴스가 풀로부터 삭제되고 있다는 것을 CSE가 인식하고 있음을 나타낼 수 있다. 대안적으로 또는 추가적으로, 노드는 CSE로부터 삭제 통지를 수신할 수 있다. 이 삭제 통지는 하나 이상의 CSF 인스턴스가 풀에서 나가도록 요청하고 있음을 나타낼 수 있다. 이 삭제 통지는 하나 이상의 CSF 인스턴스가 그 할당된 처리를 지원할 수 없다는 CSE의 결정에 기반하여 전송될 수 있다. 따라서, 노드는 풀로부터 하나 이상의 CSF 인스턴스를 삭제할 수 있다.

본 출원의 보다 견고한 이해를 용이하게 하기 위해서, 유사한 요소들에는 유사한 번호들로 참조되는 첨부 도면들에 대한 참조가 이제 이루어진다. 이러한 도면들은 본 출원을 제한하는 것으로 해석되어서는 안 되며, 단지 예시적인 것으로 의도된다.
도 1은 네트워크 기능 가상화(NFV)와 관련된 개념들을 도시하는 도면이다.
도 2는 NFV의 예시적인 구현도이다.
도 3은 가상화된 네트워크 기능(VNF) 아키텍처의 일 예를 도시하는 블록도이다.
도 4는 모바일 에지 컴퓨팅(MEC)의 일 예를 도시하는 도면이다.
도 5는 예시적인 M2M(machine-to-machine) 네트워크 아키텍처 및 서비스들을 도시하는 시스템도이다.
도 6은 서비스 계층을 지원하는 예시적인 프로토콜 스택을 도시한다.
도 7은 네트워크 내에 배포된 M2M 또는 사물 인터넷(IoT) 서비스 계층의 일 예를 도시하는 시스템도이다.
도 8은 oneM2M 서비스 계층 내의 공통 서비스 기능들(CSF들)을 도시한다.
도 9는 oneM2M 서비스 계층 리소스 지향 아키텍처를 도시하는 블록도이다.
도 10은 oneM2M 서비스 구성요소 아키텍처를 도시하는 블록도이다.
도 11은 oneM2M에서 정의된 예시적인 메시지 흐름을 도시한다.
도 12는 서비스 계층이 NFV를 적용하지 않는 예시적인 이용 사례를 도시한다.
도 13은 예시적인 실시예에 따른 예시적인 메시지 교환을 도시하는 호출 흐름이다.
도 14는 예시적인 실시예에 따른 풀 기반 M2M 서비스 계층을 위한 예시적인 기능적 아키텍처를 도시한다.
도 15는 예시적인 실시예에 따른 풀 기반 서비스 계층을 실현하기 위한 예시적인 작업들을 도시한다.
도 16은 예시적인 실시예에 따른 예시적인 후보 선택 프로세스를 도시하는 호출 흐름이다.
도 17은 예시적인 실시예에 따른 예시적인 역할 선택 프로세스를 도시하는 호출 흐름이다.
도 18은 예시적인 실시예에 따른 예시적인 역할 이전 프로세스를 도시하는 호출 흐름이다.
도 19는 예시적인 실시예에 따른 예시적인 역할 연결 프로세스를 도시하는 호출 흐름이다.
도 20은 예시적인 실시예에 따라 VNF 풀에 합류하는 공통 서비스 기능(CSF)의 인스턴스를 도시하는 호출 흐름이다.
도 21은 예시적인 실시예에 따라 VNF 풀을 떠나는 CSF의 인스턴스를 도시하는 호출 흐름이다.
도 22는 예시적인 실시예에 따른 oneM2M 서비스 계층 내의 VNF 풀 인에이블러 서비스(VPES)를 도시한다.
도 23은 예시적인 실시예에 따른 CSF 풀 제어기(CPC)에 대한 예시적인 oneM2M 리소스를 도시한다.
도 24는 예시적인 실시예에 따른 CSF 풀 관리자(CPM)에 대한 예시적인 oneM2M 리소스를 도시한다.
도 25는 예시적인 실시예에 따른 oneM2M 풀링을 나타내는 호출 흐름이다.
도 26은 예시적인 실시예에 따른 시스템과 관련된 예시적인 그래픽 사용자 인터페이스를 도시한다.
도 27은 예시적인 실시예에 따른 예시적인 CSF 풀과 관련된 예시적인 그래픽 사용자 인터페이스를 도시한다.
도 28a는 하나 이상의 개시된 실시예가 구현될 수 있는 예시적인 M2M 또는 IoT 통신 시스템의 시스템도이다.
도 28b는 도 28a에 도시된 M2M/IoT 통신 시스템 내에서 이용될 수 있는 예시적인 아키텍처의 시스템도이다.
도 28c는 도 28a에 도시된 통신 시스템 내에서 이용될 수 있는 예시적인 M2M/IoT 단말 또는 게이트웨이 디바이스의 시스템도이다.
도 28d는 도 28a의 통신 시스템의 양태들이 구현될 수 있는 예시적인 컴퓨팅 시스템의 블록도이다.

전술한 바와 같이, oneM2M 공통 서비스 계층은 공통 서비스 기능들(CSF들)의 세트를 지원하고, 하나 이상의 특정 유형의 CSF들의 세트의 인스턴스화는 공통 서비스 엔티티(CSE)로 지칭된다. 도 11을 참조하면, 공통 서비스 엔티티들(CSE들) 및 애플리케이션 엔티티들(AE들)을 수반하는 절차들은 요청 및 응답 메시지들의 이용에 기반한, 기준점들을 통한 메시지 교환에 의해 구동된다. 특히, 발신자(1101)로부터 요청 메시지(1102)를 수신하면, 그 요청(1102)의 수신자(1103)는 수신자(1103) 상에서 구현되거나 실행 중인 특정 서비스들 또는 CSF 인스턴스들을 호출하여 그 요청(1192)을 처리하고, 응답 메시지(1104)를 발신자(1101)에게 다시 전송한다.

이제 특정예의 이용 사례로 돌아가서 도 12를 참조하면, 공기 조절 제어를 위한 액추에이터인 애플리케이션 엔티티(AE-1)는 중간 노드 CSE(MN-CSE)(1203)에게 MN-CSE(1203)를 목표로 한 URI를 갖는 요청을 (1202에서) 전송한다. 이 예에 따르면, 1202에서의 요청은 원래 MN-CSE(1203) 상에서 실행되는 데이터 분석 서비스에 의해 처리되어 온도 예측을 얻는 것으로 가정된다. 일단, 예시적인 이용 사례에 따라, MN-CSE(1203)의 능력은 동적으로 확장 또는 축소될 수 없다고 가정된다. 예를 들어, M2M 영역 네트워크들로부터 수신된 너무 많은 요청들로 인해 MN-CSE(1203)에 과부하가 걸리거나, 또는 MN-CSE(1203) 상의 데이터 분석 서비스가 응답하지 않거나 아니면 이용가능하지 않은 경우, AE-1로부터의 요청은 제시간에 처리되지 않을 것이다. 본 명세서에서는, CSE에서 가외의 용량을 항상 과도하게 프로비저닝하는 솔루션은 유연성 및 에너지 효율성이 낮아 제대로 작동하지 않을 수 있다는 점에 유의해야 한다. 도 12에 도시된 예시적인 이용 사례를 계속하면, MN-CSE(1203) 상에서 실행되는 동일한 데이터 분석 서비스 인스턴스는 다른 노드들, 예를 들어 인프라스트럭처 노드 CSE(IN-CSE) 노드(1205) 상에서 실행된다. 그러나, 예시적인 이용 사례에 따르면, MN-CSE(1203)는 1202에서 수신된 요청을 처리하기 위해 IN-CSE(1205)(또는 임의의 다른 노드들) 상에서 서비스 인스턴스를 동적으로 호출할 수 없다.

도 12에 대한 이용 사례는 MN-CSE(1203)가 단순히 IN-CSE(1205)에게 요청을 전달하는 사례와 상이하다. 전달 사례에서, AE-1은 도 12와 관련하여 설명되는 예시적인 이용 사례에서와 같이 IN-CSE(1205)에 대해 타겟 URI를 구체적으로 설정하며, MN-CSE(1203)에 대해서는 그러하지 않다. 이하에서 설명되는 능력 공유 시나리오와 관련하여, AE-1은 IN-CSE(1205)가 그 요청을 처리할 것인지를 인식할 필요가 없다.

도 12에 도시된 이용 사례는 서비스 계층을 구축하기 위한 현재의 접근 방식의 한계들을 보여주는 복수의 예들 중 하나이다. 예를 들어, (CSF의 관점에서) 서비스 계층 능력들은 M2M/IoT 네트워크들에 걸쳐 상이한 CSE들 간에 효율적으로 이용되지 못할 수 있다. 후술되는 예시적인 실시예에 따르면, NFV 기술을 이용하는 M2M 서비스 계층들을 구축하고 관리하기 위한 패러다임이 설명된다. 예를 들어, NFV를 통해 풀 기반 서비스 계층들을 구축하기 위한 패러다임이 아래에 개시되어 있다. 이하의 설명의 대부분은 다양한 실시예들을 예시하기 위해 oneM2M의 맥락에서의 설명적인 예들을 포함하지만, 이러한 실시예들은 oneM2M으로 제한되지 않는다는 것을 이해할 것이다. 예를 들어, 설명되는 실시예들은 원하는 대로 다른 서비스 계층들로 구현될 수 있다.

이제 도 13을 참조하면, 예시적인 oneM2M 시스템이 도시되어 있다. 도 13에 도시된 바와 같이, oneM2M 공통 서비스 계층에 대해, CSE들 및 AE들을 수반하는 절차들은 기준점들을 통한 메시지 교환에 의해 구동되며, 일반적인 흐름은 도 11과 관련하여 설명되는 바와 같이 요청 및 응답 메시지들의 이용에 기반한다. 특히, 도 13에 도시된 바와 같이, 발신자(1101)로부터 요청을 수신하면, 수신자(1103)는 1302에서 요청 처리 단계를 수행한다. 1302에서의 요청 처리 단계는 요청을 처리하고 처리된 결과를 획득하는 단계를 포함할 수 있다. 처리된 결과는 1104에서 응답 메시지로 발신자에게 다시 전송될 수 있다.

1302에서의 요청 처리 단계 동안, 이하에서 추가로 설명되는 바와 같이, 하나 이상의 상이한 서비스 능력 또는 CSF 소프트웨어 인스턴스가 요청을 처리하기 위해 호출될 수 있다. 현재의 oneM2M 실행들에 따르면, 1302에서의 요청 처리는 CSE 내에 있다. CSE는 예를 들어 부하 균형과 같은 특정 내부 최적화들이 지원되는 중앙 집중식 클러스터를 이용하여 실현될 수 있다. 그러나, 후술되는 실시예들에서, CSF 또는 서비스 능력은 상이한 CSE들 간에 공유될 수 있다. 도 13을 참조하면, (1102에서) 주어진 CSE(예를 들어, 수신자(1103))에 의해 수신되는 서비스 계층 요청이 서비스 계층을 구축하기 위해 NFV가 이용되는 구현예들에서의 1302에서 어떻게 처리될 수 있는지, 및 CSF 또는 서비스 능력이 CSE들 간에 어떻게 공유되는지에 대해 후술한다. 일 실시예에서, 상이한 CSE들 상에서 호스팅되거나 실행되는 CFS들 또는 서비스 능력들(예를 들어, 소프트웨어 인스턴스들)은 1302에서 요청을 처리하기 위해 동적 및 협업적으로 활용된다.

이제 도 14를 참조하면, 예시적인 아키텍처(1400)는 NFV를 통해 구현되는 풀 기반 서비스 계층을 포함한다. NFV를 이용하면, M2M/IoT 노드들의 물리적 리소스들이 하이퍼바이저에 의해 가상 기계들(VM들)로 가상화될 수 있다. 따라서, M2M 노드 상에서 실행되는 상이한 네트워크 기능 소프트웨어 인스턴스들(예를 들어, CSF들 또는 서비스 능력들)은 필요에 따라 동적으로 배포/실행/M2M 노드로부터 삭제됨으로써 주어진 CSE(예를 들어, ASN-CSE(1402), MN-CSE(1404) 또는 IN-CSE(1406))를 구성할 수 있다. ASN-CSE(1402), MN-CSE(1404) 및 IN-CSE(1406)는 각각 일반적으로 M2M 노드로 지칭될 수 있음을 이해할 것이다. 특히, 예를 들어 후술하는 바와 같이 상이한 CSE들 상에서 호스팅되는 서비스 능력 소프트웨어 인스턴스들 또는 CSF는 대응 VNF 풀들에 합류할 수 있으며, 본 명세서에서 CSF 풀들로 또한 지칭될 수 있는 그 VNF 풀들의 CSF 풀 관리자들(CPM들)에 의해 관리될 수 있다. CSF 풀은 일반적으로 동일한 네트워크 기능을 제공하는 복수의 CSF 인스턴스들을 지칭한다. CSF 풀 멤버는 일반적으로 CSF 풀에 합류하고 그 풀의 CPM에 의해 관리되는 물리적 CSF 인스턴스를 지칭한다. CPM은 일반적으로 CSF 인스턴스들을 제공하기 위해 CSF 풀 제어기(CPC)를 관리하고(예를 들어, 풀 멤버들을 관리/호출/스케줄링하고) 이와 상호작용하는 논리 엔티티를 지칭한다.

본 명세서에서 설명되는 실시예들을 설계함에 있어서, 본 명세서에서는 M2M/IoT 시스템들에서의 노드들이 리소스 제한될 수 있으며, 예를 들어 수신자 CSE의 제한된 처리 능력으로 인해 서비스 계층 요청이 적시에 처리되지 않을 수 있음을 알아야 한다. 따라서, 수신자 CSE는 동등한 것들에게 도움을 요청할 수 있다. 특히, 본 명세서에서 설명되는 풀링 메커니즘들은 CSF 인스턴스들이 요구형 방식으로 공유되고 동적으로 프로비저닝되도록 허용할 수 있다. 본 명세서에서는 M2M 노드들이 흔히 에너지 효율 목적들을 위해 휴면 스케줄들을 갖는다는 것을 또한 알아야 한다. 따라서, 예를 들어 주기적 휴면으로 인해 주어진 CSF 인스턴스가 이용가능하지 않게 될 때, 예시적인 실시예에 따라 풀링 메커니즘에 의해 지원되는 즉각적인 백업 CSF 인스턴스가 프로비저닝될 수 있다.

도 14를 다시 참조하면, 아키텍처(1400)는 하나 이상의 CSF 풀 제어기(CPC), 예컨대 CSF 풀 제어기(CPC)(1408), 및 하나 이상의 CSF 풀 관리자(CPM), 예컨대 제1 CPM(1410a) 및 제2 CPM(1410b)을 포함할 수 있다. 예시적인 목적들을 위해 2개의 풀(VNF 풀 A 및 VNF 풀 B)이 도시되었지만, CPC(1408)는 임의의 수의 풀들을 원하는 대로 제어할 수 있음을 이해할 것이다. 도 14에 도시된 바와 같이, CPC(1408) 및 CPM들(1410a 및 1410b)은 논리적 기능들일 수 있다. 따라서, CPC 및 CPM 기능들은 네트워크 내의 특정 CSE들에 의해 수행될 수 있다. 달리 지정되지 않는 한, CSE 노드 및 M2M 노드라는 용어들은 본 명세서에서 상호교환적으로 사용될 수 있다는 것을 이해할 것이다. 풀들(VNF 풀 A 및 VNF 풀 B)은 그 풀들에서의 CSF 소프트웨어 인스턴스들이 M2M 네트워크에 걸쳐 물리적으로 분산될 수 있다는 점에서 논리적 풀들일 수 있다. 예로서, 도시된 바와 같이, VNF 풀 A(CSF-A 풀이라고도 지칭될 수 있음)는 M2M 영역 네트워크에서 ASN-CSE(1402) 상에서 호스팅되는 물리적 소프트웨어 인스턴스 CSF-A#1을 포함한다. CSF-A 풀은 또한 IN-CSE(1406) 측에서 호스팅되는 물리적 소프트웨어 인스턴스 CSF-A#2를 포함한다. 본 명세서에서 사용되는 CPC는 일반적으로 다양한 CSF들을 결합하고 조율하는 방법을 결정하는 서비스 제공자의 논리 엔티티를 지칭할 수 있다.

예시적인 실시예에서, 수신자 CSE에 의해 수신된 주어진 서비스 계층 요청은 로컬로 처리될 수 있거나, 또는 수신자 CSE는 CPC(현재 CPC의 역할을 하고 있는 다른 CSE일 수 있음)와 접촉할 수 있고, CPC는 (예를 들어, 풀로부터 상이한 CSF 인스턴스들을 호출하여) 적합한 CPM들에게 그 요청을 처리하도록 요청할 수 있다. CPC는 처리된 결과를 수신자 CSE에게 회신할 수 있으며, CSE는 그 요청의 발신자에게 응답 메시지를 다시 전송할 수 있다. 요청 처리 세부사항들은 투명하거나 그 요청의 발신자로부터 숨겨질 수 있다.

본 명세서에서 설명되는 바와 같이, 주어진 CSE는 서로 배타적이지 않을 수 있는 다양한 역할들을 맡을 수 있다. 예를 들어, CSE는 oneM2M 서비스 계층 맥락에서 설명되는 바와 같이 서비스 계층 요청 발신자일 수 있다. CSE는 VNF 풀들에 의해 제공되는 CSF 인스턴스들을 이용하여 그 수신된 요청들을 처리하기 위해 CPC와 접촉하는 경우 VNF 풀 "CSF 리소스 소비자"일 수도 있는 서비스 계층 요청 수신자일 수 있다. 예를 들어, CSE가 하나 이상의 CSF 인스턴스를 실행하고, CSE가 그 CSF 인스턴스들을 CPM들에 의해 관리되는 대응 VNF 풀들에 합류시키려는 경우, 주어진 CSE는 VNF 풀 "CSF 리소스 제공자"일 수 있다.

예시적인 실시예에서, 이하에서 상세히 설명되는 바와 같이, 서비스 제공자(SP)는 도 14와 관련하여 설명되는 풀 기반 아키텍처를 실현하기 위해 복수의 CSE들이 배포된 주어진 M2M 네트워크를 구성할 수 있다. 예를 들어, SP는 특정 CSE들에게 논리적 역할들(예를 들어, CPC, CPM 등)을 할당할 수 있다. 또한, 상이한 유형들의 CSF 인스턴스들이 VNF 풀들에 합류할 수 있고 대응 CPM들에 의해 관리될 수 있으므로, 풀 관리를 지원하는 특정 절차들 또는 메커니즘들이 아래에 설명되어 있다.

특히, 예를 들어, VNF 풀 인에이블러 서비스(VPES)로 지칭되는 CSE의 새로운 서비스가 본 명세서에 개시되어 있다. VPES는 본 명세서에서 설명되는 VNF 풀 기반 서비스 계층을 구축하는데 도움이 될 수 있다. VPES를 이용하여, 도 15에 도시된 바와 같이, 서비스 계층 설정, 배포 및 풀 관리와 관련된 작업들이 수행된다.

도 15를 참조하면, CPC 역할들이 할당된다. 도시된 예에 따라, SP는 VPES의 지원하에 CPC의 역할을 수행하도록 CSE-1을 할당한다. 일부 사례들에서, CPC는, 수신자 CSE가 하나 이상의 VNF 풀에서 CSF 소프트웨어 인스턴스를 이용하여 서비스 계층 요청을 처리하려는 경우, 수신자 CSE는 먼저 CPC와 접촉할 것이라는 점에서 VNF 풀 기반 시스템의 포털이다. 도시된 바와 같이, SP는 CSE(CSE-2)가 (VPES의 지원하에) CPM의 역할을 하도록 할당할 수 있고, CPM을 CPC의 역할을 수행하도록 할당된 CSE-1과 링크시킬 수 있다. 이러한 CPM 할당 작업은 복수의 유형들의 CSF들이 있을 수 있기 때문에 여러 번 실행될 수 있으며, 각각의 유형의 CSF는 그 대응 풀을 관리하기 위해 CPM을 요구할 수 있다. 이제 풀 관리를 위한 도시된 작업을 참조하면, CPM은 CSF 인스턴스들이 풀에 합류하거나 나갈 수 있게 하는 특정 메커니즘들을 수행할 수 있다. 일단 도시된 작업들이 수행되면, 풀 기반 서비스 계층은 시스템 전체의 동적 CSF 리소스 풀링 및 공유 측면에서 구현될 수 있다.

대안적인 예에서, SP는 배포 전에 특정 역할들을 갖는 CSE를 사전 구성할 수 있으며, 도 15에 도시된 작업들은 수행되지 않는다. 이러한 구현에서는 사전 구성이 배포 전에 수행될 수 있다. 그러나, 앞서 언급했듯이, M2M/IoT 시스템들에는 흔히 다양한 동적 변경들이 있다. 예를 들어, M2M 노드들은 휴면할 때 이용가능하지 않게 될 수 있다. 따라서, 배포 후 네트워크를 동적으로 설정하거나 구성하려면 특정 작업들을 SP가 수행해야 할 수 있다. 또한, 이러한 작업들은 후술하는 바와 같이 매우 분산된 M2M/IoT 네트워크들에 맞게 조정해야 할 수 있다.

CPC 할당을 위한 작업이 이제 더 상세히 논의될 것이다. M2M/IoT 네트워크들 또는 시스템들은 흔히 클라우드 또는 데이터 센터들에서의 애플리케이션 시나리오와는 상이한 다양한 동적 변경들을 경험한다. 예를 들어, 에너지를 보존하는 주기적인 휴면으로 인해 M2M 노드들을 이용할 수 없게 될 수 있다. 또한, M2M 노드들은 클라우드들 또는 데이터 센터들에서의 컴퓨팅 노드들의 정적 배포와 비교하여 더 많은 이동성 특성들을 가질 수 있다. 또한, 많은 사례들에서, M2M/IoT 노드들은 리소스가 제한되어 있으므로 특정 CSE에 역할을 할당할 때 리소스 소비 측면을 고려해야 한다. 따라서, 본 명세서에서는, M2M/IoT 네트워크들에서 공인된 CSE에게 서비스 제어 엔티티(SCE) 역할을 할당하는 것이 사소한 작업이 아닐 수 있다는 것을 알아야 한다.

일부 사례들에서는, M2M/IoT 시스템들과 관련된 다양한 요구사항들을 해결하기 위해, 후보 선택 프로세스(CSP), 역할 할당 프로세스(RAP) 및 역할 이전 프로세스(RMP)가 수행되어 CPC 할당을 위한 작업을 달성할 수 있다. 분산된 M2M 네트워크에서의 예시적인 CSP와 관련하여, M2M 노드들은 다양한 실시간 처리로 인해 동적 용량 상태를 가질 수 있다. 따라서, CSP는 그 현재 용량들에 기반하여 다수의 후보 CSE들을 평가할 수 있으며, CPC 역할을 맡을 수 있는 최상의 CSE를 선택할 수 있다. 예시적인 RAP와 관련하여, 일부 사례들에서는, CSP 프로세스 동안 특정 CSE가 선택되면, SP는 특정 동작들을 수행하여 선택된 CSE에게 역할을 할당할 수 있다. 예시적인 RMP와 관련하여, 일부 사례들에서는, M2M/IoT 네트워크들에서 발생하는 변경들 또는 이벤트들을 고려할 때, 선택된 CSE는 몇몇 시점에서 더 이상 CPC로서 작동할 수 없을 수 있다. 따라서, CPC 역할은 상이한 CSE들 간에 동적으로 이전될 수 있다.

이제 도 16 내지 도 21을 전반적으로 참조하면, 예시적인 방법들은 SP 및 복수의 CSE들을 포함하는 시스템(또는 네트워크)에서 수행된다. 예를 들어, CSE들은 VPES를 포함하는 CSE-1, VPES를 포함하는 CSE-2, 및 VPES를 포함하는 CSE-3을 포함할 수 있다. 예시적인 시스템은 개시된 주제의 설명을 용이하게 하기 위해 간략화되지만 본 개시내용의 범위를 제한하려는 의도는 아니라는 것을 이해할 것이다. 다른 디바이스들, 시스템들 및 구성들은 도 16 내지 도 21에 도시된 네트워크와 같은 시스템에 추가하여 또는 그 대신에 본 명세서에 개시된 실시예들을 구현하는데 이용될 수 있으며, 이러한 모든 실시예들은 본 개시내용의 범위 내인 것으로 고려된다.

특히 도 16을 참조하면, 예시적인 후보 선택 프로세스(CSP)가 도시되어 있다. 1에서, 도시된 예에 따르면, SP는 이미 시스템에서 CPC로서 작동하는 CSE가 없는 것으로 확인된다고 가정한다. 1에서, SP는 CPC의 역할을 수행할 수 있는 적합한 CSE를 네트워크에서 찾고자 한다. 따라서, SP, 예컨대 SP가 실행하는 관리 애플리케이션은 일괄 요청들을 하나 이상의 CSE에게 전송할 수 있다. 따라서, SP는 복수의 공통 서비스 엔티티들에게 요청을 전송할 수 있다. 도시된 바와 같이, CSE-1은 요청을 수신하고 그 요청과 연관된 동작들을 수행하는 CSE들 중 하나의 예이다. 일부 사례들에서, CSC가 본 명세서에서 설명되는 아키텍처에서 중요한 역할을 담당할 수 있으므로, SP는 신뢰할 수 있는 CSE들에게만 요청을 전송한다. 그렇게 함으로써, SP는 선택된 신뢰할 수 있는 CSE들로부터 다양한 정보를 수집할 수 있다. 이 정보는, 예를 들어 그리고 제한 없이, 노드의 성능과 관련된 정보, 노드의 이용가능성과 관련된 정보 및 보안 관련 정보를 포함할 수 있다. 예를 들어 성능과 관련하여, SP는 강력한 노드가 CPC 역할을 하도록 요구할 수 있다. 따라서, SP는 강력한 에지 컴퓨팅 능력들을 갖춘 M2M 서버 또는 게이트웨이를 선택할 수 있다. 노드의 이용가능성과 관련하여, SP는 CPC 역할을 위해 일반적으로 이용가능한 CSE를 선택할 수 있다. 예로서, SP는 M2M 서버 또는 게이트웨이가 가장 이용가능하다고 결정할 수 있으며, 이에 따라 M2M 서버 또는 게이트웨이는 디폴트로 제1 옵션일 수 있다. 대안적으로, M2M 서버 또는 게이트웨이 이외의 다른 노드들이 CPC로서 선택될 수 있다는 것을 이해할 것이다. 보안 정보와 관련하여, SP는 적합한 보안 메커니즘을 갖는 CSE를 선택하여 보안 문제들 및 위협들 없이 시스템을 실행할 수 있다. 요청들을 전송하기 위해, SP는 기존의 oneM2M 그룹 동작을 이용하여 신뢰할 수 있는 CSE들을 포함하는 그룹을 먼저 정의할 수 있다. 따라서, SP가 CPC가 될 적합한 CSE를 찾아야 하는 경우, SP는 정의된 <group> 리소스를 통해 그룹 통신 동작들을 수행하여 그 CSE들에게 요청을 전송할 수 있다.

계속해서 도 16을 참조하면, 2에서, 도시된 예에 따르면, SP는 CSE-1의 현재 성능 용량을 질의하고 CSE-1이 CPC가 되려고 하는지 여부를 질의한다. 일 예에서, 요청은 각각의 CSE의 현재 용량 및 각각의 CSE가 CPC가 되려고 하는지 여부를 질의할 수 있다. 특히, CSE-1의 VPES는 질의들에 응답할 수 있다. 일부 사례들에서, NFV 기술이 이용되므로, 이용가능한 컴퓨팅/저장 리소스들이 이용가능한 VM 리소스들 측면에서 설명될 수 있다. 2에서 전송된 메시지는 예로서 그리고 제한 없이 다음과 같은 다양한 데이터 필드들을 포함할 수 있다:

발신자 ID(s_id): 이것은 메시지가 SP로부터 전송되었음을 수신자에게 통보하기 위해 발신자의 아이덴티티를 식별한다.

메시지 유형(m_t): 메시지 유형은 요청의 목적을 나타낼 수 있다. 예를 들어, 수신자 CSE는 메시지 유형으로부터 자신이 CPC가 되려고 하는지 여부를 SP가 묻고 있다는 것을 알 수 있다.

지속시간(t_d): 일부 사례들에서, SP는 주어진 기간 동안 CPC를 원하며, 이것은 지속시간 파라미터로 표시될 수 있다.

질의할 성능 데이터의 유형(p_list): SP는 수신자에게 SP가 관심 있는 성능 데이터 유형들을 나타낼 수 있으며, 수신자 CSE는 SP가 필요로 하지 않을 수 있는 성능 데이터를 너무 많이 회신할 필요가 없다. 예로서, 데이터 필드들의 리스트는 CPU, RAM, 저장소 등과 같은 성능 유형들을 지정할 수 있다.

연결성(con): SP는 예를 들어 수신자 CSE가 CPC가 될 좋은 후보인지 여부를 결정하기 위해 수신자 CSE의 연결성 정보에 또한 관심을 가질 수 있다. 예를 들어, CPC가 네트워크에서의 복수의 노드들 간에 조정 및 협력 동작들을 수행할 수 있기 때문에 네트워크들에서의 다른 노드들과의 연결성이 좋지 않으면 CSE는 CPC로 작동해서는 안 된다.

3에서, 도시된 예에 따라, CSE-1의 VPES는 그 OS 또는 하이퍼바이저(예를 들어, 이용가능한 VM 리소스들)와 상호작용함으로써 그 실행 시간 용량 데이터를 수집한다. CSE-1의 VPES는 또한 그 로컬 시스템 정책에 기반하여 CPC로 작동할 수 있는지 여부를 결정할 수 있다. 일부 사례들에서, 특정 CSE에 CPC로 작동하기에 충분한 VM 리소스들이 있는 경우, 로컬 시스템 정책들이 이를 수행하도록 허용해야 할 필요가 있을 수 있다. 예를 들어, 주어진 노드의 VM 리소스들을 특정 애플리케이션들 또는 사용자들만이 이용할 수 있도록 일부 노드들을 사용자들이 구성할 수 있다. 따라서, 이들 노드들은 CPC로서 작동하려고 한다는 것을 SP에게 나타낼 수 없을 수 있다. 마찬가지로, 일부 보안 관련 정책들은 또한 노드가 CPC로서 작동할 수 없는 동일한 상황을 야기할 수 있다. 도시된 바와 같이, 4에서, CSE-1은 응답에서 SP가 요구하는 전술한 정보를 다시 전송한다. 4에서의 메시지는 예를 들어 그리고 제한 없이 다음과 같은 다양한 데이터 필드들을 포함할 수 있다:

수신자 ID(r_id): 메시지 수신자의 아이덴티티는 그 응답이 후보 CSE에서 온 것임을 SP에게 통보한다.

응답 유형(r_t): 이 데이터 필드는 수신자 CSE가 CPC가 되려고 하는지 여부를 SP에게 통보할 수 있다.

세부 성능 데이터(dp_list): 수신자 CSE는 예를 들어 요청 메시지에 지정된 대로 SP의 관심에 기반하여 성능 데이터 리스트를 SP에게 회신할 수 있다. 예를 들어, 성능 데이터는 VM에 의해 지원되는 CPU, 이 VM에 의해 지원되는 RAM, 이 VM에 의해 지원되는 저장소, 이 VM에 의해 지원되는 SLA(서비스 수준 합의), 이 VM 상에서 실행되는 운영 체제, 휴면 스케줄 또는 CPC가 될 이용가능한 기간 등을 포함할 수 있지만 이에 제한되지는 않는다. 1에서 CPC에 노출된 이전 정보와 비교하여, 본 명세서에서의 데이터는 현재 이용가능한 VM을 설명하는 더 많은 실행 시간 데이터를 포함한다.

토폴로지 정보(t_i): 수신자 CSE는 그 연결 상태를 나타낼 수 있는 그 토폴로지 정보를 SP에게 통보할 수 있다.

전술한 바와 같이, 네트워크에는 (CSE-1 이외에) 복수의 후보 CSE들이 있을 수 있으므로, SP와 다른 후보 CSE들 간에 단계들(2-4)이 수행될 수 있다. 따라서, 요청에 응답하여, SP는 복수의 공통 서비스 엔티티들로부터 복수의 응답들을 수신할 수 있고, 각각의 응답은 각각의 CSE가 공통 서비스 기능(CSF) 풀 제어기(CPC)일 수 있는지 여부에 관련된 정보를 포함할 수 있다.

계속해서 도 16을 참조하면, 도시된 예에 따라, 5에서, SP가 후보 CSE들로부터 정보를 수집하면, SP는 다양한 기준들을 이용하여 후보 CSE를 평가하고, 어떤 CSE가 CPC 역할을 가장 잘 맡을지를 결정한다. 예를 들어, SP는 CPC 역할에 가장 적합한 CSE가 이용가능한 가장 강력한 VM들을 갖는 CSE라고 결정할 수 있다. 따라서, SP는 복수의 공통 서비스 엔티티들로부터 적어도 하나의 CPC를 선택하기 위해 각각의 응답으로부터의 정보를 평가할 수 있다. 6에서, CPC 역할을 수행하기 위해 후보 CSE(도시된 예에서의 CSE-1)가 SP에 의해 선택되면, SP는 기본 또는 선호 성능 요구사항들을 지정하여 CSE-1에 대한 역할 프로파일을 공식적으로 맞춤화할 수 있다. 따라서, SP는 적어도 하나의 CPC에 대한 역할 프로파일을 생성할 수 있다. 역할 프로파일은 CPC의 가상 기계에 대한 최소 성능 요구사항, CPC의 가상 기계에 대한 선호 성능 시간, 역할 이전 전략 및 역할 소프트웨어 업데이트 스케줄 중 적어도 하나를 포함할 수 있다. 일 예에서, 역할 프로파일은 공통 서비스 엔티티들 중 하나를 백업 CSE로 식별하며, 적어도 하나의 CPC는 CPC의 역할을 백업 CSE로 이전할 수 있다. 다른 예에서, M2M 노드들이 주기적인 휴면으로 인해 때때로 이용가능하지 않게 될 수 있다는 것을 고려하여, SP는 복수의 CSE들을 선택하고 각각이 CPC로서 작동하도록 이들에 대한 온 듀티(on-duty) 스케줄을 산출할 수 있다. 따라서, SP는 복수의 CSF 풀 제어기들을 선택할 수 있고, 역할 프로파일은 각각의 CSF 풀 제어기와 연관된 온 듀티 시간을 추가로 포함할 수 있다. 일부 사례들에서, 일단 후보들이 선택되면, SP는 도 17과 관련하여 상세히 후술하는 역할 할당 프로세스를 수행하기 시작할 수 있다.

역할 프로파일 생성과 관련하여, 특정 역할 프로파일 템플릿들이 역할 프로파일들을 생성하기 위해 정의될 수 있다. 예를 들어, 표 1은 예시적인 역할 프로파일에 나열될 수 있는 예시적인 데이터 아이템들을 보여준다. 예를 들어, 관련된 당사자들이 날짜 아이템들의 의미를 명확히 하는 합의를 갖는다고 가정하면, 다른 데이터 아이템들은 원하는 대로 포함될 수 있음을 이해할 것이다. 예를 들어, SP는 기본/선호 성능 요구사항들 및 예외 처리 규칙들(예를 들어, 어떤 예외 발생시 CPC 역할을 대신할 수 있는 백업 CSE)을 기반으로 CSE-1에 대한 역할 프로파일을 맞춤화할 수 있으며, 이것은 추후의 자체 구성을 위한 CSE-1의 지침이다.

<표 1>

이제 도 17을 참조하면, 역할 할당을 위한 예시적인 전제 조건으로서, CSE-1이 CPC로 선택되었으며(도 16 참조), 이제 SP는 CPC의 역할을 수행하도록 CSE-1을 지정하려고 한다. 1에서, 도시된 예에 따라, SP는 CSE-1에게 역할 프로파일을 전달함으로써 선택된 후보 CSE(CSE-1)에게 CPC 역할을 부여한다. 따라서, 일 예에서, 역할 프로파일은 복수의 공통 서비스 엔티티들 중 적어도 하나의 CSE에게 전송될 수 있다. 역할 프로파일은 SP가 CSE-1에게 CPC 역할을 할당했다는 것을 CSE-1에게 통보할 수 있다. 1에서의 메시지는 다양한 데이터 필드들을 포함할 수 있으며, 이들 중 적어도 일부는 표 1에 도시된 예시적인 역할 프로파일로부터 온 것일 수 있다. 데이터 필드들은 예로서 그리고 제한 없이 제시된 다음과 같은 것들을 포함할 수 있다:

발신자 ID(s_id): 메시지 발신자의 아이덴티티는 메시지가 SP에서 온 것임을 수신자에게 통보한다.

메시지 유형(m_t): 메시지 유형은 메시지의 목적들을 나타낼 수 있다. 예를 들어, 수신자 CSE는 SP가 메시지 유형으로부터 CPC 역할을 그에게 할당하고 있음을 통보 받을 수 있다.

프로파일 식별자(p_i)

역할 이름(수신자 CSE가 m_t 메시지로부터 이 정보를 알 수 있는 경우 임의적임)

백업 CSE(bk_cse)

역할의 소프트웨어 소스(sw_source)

최소 VM 성능 요구사항(min_perf)

선호 VM 성능 요구사항(perfered_perf)

온 듀티 시간(듀티)

역할 이전 전략(mig)

역할 소프트웨어 업데이트 스케줄(sw_upd_time)

계속해서 도 17을 참조하면, 2에서, 도시된 실시예에 따라, CSE-1의 VPES는 역할 프로파일에 표시된 대로 필요한 VM 리소스들을 예비하려고 시도함으로써 이 역할을 수락하는지를 나타내는 응답을 전송한다. 따라서, 역할 프로파일에 응답하여, SP는 적어도 하나의 CSE로부터 확인응답(ack)을 수신할 수 있고, ack는 적어도 하나의 CSE가 역할 프로파일에 표시된 대로 그 가상 기계 리소스들을 예비하기 시작할 것임을 나타낼 수 있다. 일부 사례들에서, CSE-1은 이전에 SP에게 CPC로서 작동하려고 한다는 것을 표시했더라도 그렇게 하지 못했을 수 있다. 예를 들어, 특정 소프트웨어 설정 및 구성들은 후술된 바와 같이 수행될 필요가 있을 수 있다. 이러한 동작들은 시간이 걸릴 수 있으므로, 2에서, CSE-1은 SP가 새로운 CSP를 초기화하지 않도록 CSE-1이 역할 프로파일에 표시된 대로의 성능 요구사항들을 충족시키는데 동의함을 신속하게 SP에게 나타낼 수 있으며, CSE-1은 비동기 방식으로 전술한 바와 같은 필요한 동작들을 추가로 수행할 수 있다.

2에서의 ack 메시지는, 예를 들어 응답 유형(r_t)과 같은 다양한 데이터 필드들을 포함할 수 있으며, 이는 수신자 CSE가 역할 프로파일에 표시된 대로 성능 요구사항을 충족시키는데 동의하는지 여부를 나타낸다. 3에서, CSE-1로부터 긍정적인 ack를 얻으면, SP는 CPC 소프트웨어 패키지를 CSE-1에 배포하기 시작할 수 있다. 소프트웨어 패키지는 CSE가 그 자신을 CPC가 되도록 구성하게 할 수 있다. 일부 사례들에서, CPC(또는 CPM)로 작동하기 위해, CSE는 대응 소프트웨어를 실행할 필요가 있을 수 있다. VPES는 소프트웨어 실행을 담당할 수 있다. 유사하게, 가상화 기술이 M2M 노드들 상에서 이용된다고 가정할 수 있으며, 따라서 이러한 CPC 소프트웨어는 역할 프로파일에 표시된 대로의 성능 사양들을 가진 VM 상에서 설정되고 실행될 수 있다. 대안적으로, SP는, CSE-1의 VPES가 예를 들어 소프트웨어 저장소로부터 소프트웨어 패키지를 검색할 수 있도록, 예를 들어 특정 URI를 이용하여 CPC 소프트웨어를 어디서 다운로드할지를 CSE-1에게 통보할 수 있다. 따라서, SP는 적어도 하나의 CSE에게 표시를 전송할 수 있으며, 이 표시는 적어도 하나의 CSE가 그 자신을 CPC가 되도록 구성하게 할 수 있다. 예를 들어, SP는 임의적으로 디지털 인증서를 생성하여 이를 CSE-1에게 할당할 수 있다. 인증서에는 CSE-1이 CPC로서 기능한다는 표시(예를 들어, cpc1.SP.com 형태의 아이덴티티)가 포함될 수 있다. 인증서는 정책들에 따라 결정될 수 있는 한정된 기한을 갖는 임시 인증서일 수 있다. 인증서의 신청 및 프로비저닝은 공개 키 표준들 등을 이용하여 수행될 수 있다.

3에서의 메시지는 링크 데이터 필드를 포함할 수 있다. 예를 들어, 역할 프로파일에 단계(1)에 도시된 바와 같이 다운로드 URL이 이미 포함된 경우, SP는 링크 = 널(null)을 설정하여 CSE가 역할 프로파일에 포함된 URL을 이용하여 소프트웨어를 다운로드할 수 있게 한다. 대안적으로, SP는 이 데이터 필드를 이용하여 수신자 CSE(상이한 소프트웨어 저장소에서 소프트웨어를 다운로드하도록 수신자 CSE에게 동적으로 지시하는데 이용될 수 있음)에게 전송할 URI 링크를 포함하게 할 수 있다. 4에서, 도시된 예에 따라, CSE-1은 CPC 소프트웨어를 획득하고, CSE-1의 VPES는 역할 프로파일에 표시된 파라미터들에 기반한 CPC 소프트웨어의 설치 및 CPC 소프트웨어 인스턴스의 구성을 담당한다. VPES는 소프트웨어를 설치하기 전에 그 소프트웨어의 무결성과 진위성을 검증할 수 있다. 5에서, 단계(4)를 수행한 후, CPC는 CSE-1에 성공적으로 배포되며, CSE-1은 CPC로 작동한다. 따라서, CSE-1은 역할 할당 프로세스가 완료되었음을 나타내는 확인을 SP에게 전송할 수 있다. 5에서의 메시지는 수신자 CSE가 성공적으로 CPC의 역할을 맡았는지 여부를 나타내는 응답 유형(r_t) 데이터 필드를 포함하는 ack 메시지일 수 있다.

이제 도 18에 도시된 예시적인 역할 이전 프로세스(RMP)로 돌아가면, 도시된 호출 흐름은 CSE-1이 현재 시스템에서 CPC로서 작동하고 있는 것으로 가정한다. 도시된 바와 같이, 이러한 예에 따르면, CSE-1은 시스템 문제에 직면하여 더 이상 CPC로서 작동할 수 없다. 일 예에서, 역할 프로파일에 표시된 백업 CSE가 있는 경우, CSE-1의 VPES는 단계들(1-4)에 도시된 바와 같이 CPC 역할을 백업 CSE(예를 들어, 이 사례에서는 CSE-2)에게 직접 이전하기 시작할 수 있다. CSE-1 및 CSE-2는 자격증명들(예를 들어, SP에 의해 발행된 인증서)에 기반하여 서로를 상호 인증할 수 있고, 또한 이전 프로세스의 승인을 체크할 수 있다.

1에서, 도시된 예에 따라, VPES는 역할 프로파일을 CSE-2에게 전달함으로써 CPC 역할을 백업 CSE(예를 들어, 이 사례에서는 CSE-2)에게 이전시키는 것을 담당한다. 앞에서 언급했듯이, SP는 CSE-1에 대한 역할 프로파일을 정의할 때, CSE-1에 대한 백업 CSE를 이미 선택하였을 수 있다. 이 사례에서, CSE-1의 VPES는 CSE-2가 CSP 동안 CPC의 역할을 또한 맡으려고 한다는 것을 SP에게 이미 표시하였을 수 있기 때문에 역할 이전을 위해 CSE-2의 VPES와 직접 대화할 수 있다. 도 17에 도시된 단계(1)와 유사하게(양쪽 메시지는 역할 프로파일을 전달하고 있음), 도 18의 1에서의 메시지는 예로서 그리고 제한 없이 제시된 다음의 날짜 필드들을 포함할 수 있다:

발신자 ID(s_id): 메시지 발신자의 아이덴티티는 메시지가 현재 CPC로서 작동하고 있는 CSE로부터 온 것임을 수신자에게 통보한다.

메시지 유형(m_t): 메시지 유형은 이 메시지의 목적들을 나타낸다. 즉, 메시지 유형으로부터, 수신자 CSE는 발신자 CSE가 CPC 역할을 그에게 이전하고 있음을 알게 될 것이다.

프로파일 식별자(p_i)

역할 이름(예를 들어 수신자 CSE가 m_t 필드로부터 이 정보를 결정할 수 있는 경우 임의적임)

백업 CSE(bk_cs)는, 예를 들어 원래의 역할 프로파일에 하나의 백업 CSE만이 있는 경우, 이때에는 널로 설정될 수 있다.

역할의 소프트웨어 소스(sw_source)

최소 VM 성능 요구사항(min_perf)

선호 VM 성능 요구사항(perfered_perf)

온 듀티 시간(듀티)

역할 이전 전략(mig)

역할 소프트웨어 업데이트 스케줄(sw_upd_time)

2에서, 도시된 예에 따라, CSE-2는 이 역할 이전을 완료하기 위해 반드시 CPC로서 실제로 작동할 수 있어야 하는 것은 아니다. 특히, CSE-2의 VPES는 현재 CPC로서 기능할 수 없다고 결정하면 역할 이전 요청을 직접 거절할 수 있다. 대안적으로, CSE-2의 VPES는 현재 CPC 소프트웨어 패키지가 없는 경우 이를 다운로드하기 위해 SP와 접촉할 수 있거나, 또는 대안적으로 여전히 CSE-1은 (예를 들어, 특정 URI를 통해) 어디에서 CPC 소프트웨어를 다운로드할지를 CSE-2에게 통보할 수 있다. 또한, CSE-2는 CPC 소프트웨어를 획득하면, 도 17과 관련하여 설명된 단계들(3 및 4)과 유사하게, 역할 프로파일에 표시된 파라미터들에 기반하여 CPC 소프트웨어를 또한 설치하고 이를 구성할 수 있다.

역할 이전 중에, 특정 구현예들에 따라, 상이한 특징들이 지원될 수 있다. 일 예에서, CSE-1은 CPC 역할을 CSE-2로 이전하고, CSE-1이 관리하는 라이브 CPC 관련 작업들은 종료된다. 대안적으로, 라이브 CPC 관련 작업들을 종료하지 않고 CSE-2로 또한 이전할 수 있다.

3에서, 도시된 예에 따라, CSE-2는 CSE-1에게 응답(2와 관련하여 논의된 바와 같은 성공 또는 실패)을 전송한다. 도 17에 도시된 단계(5)와 유사하게, 3에서의 ack 메시지는 수신자 CSE가 성공적으로 CPC 역할을 인수했는지 여부를 나타낼 수 있는 응답 유형(r_t) 데이터 필드를 포함할 수 있다. 4에서, CSE-2로부터 수신된 응답과 관련하여, 이전이 성공했다는 것을 응답이 나타내면, CSE-2는 이제 CPC로 작동할 수 있다. 특히, CSE-1은 시스템에서의 다른 CSE들(예를 들어, CPC 관련 처리 또는 동작들을 위해 과거에 CSE-1에 접촉한 CSE들)에게 자신이 CPC 역할을 더 이상 수행하지 않고 CPC 역할과 관련하여 향후 들어오는 모든 트래픽은 CSE-2로 전달되어야 한다는 것을 선언할 수 있다. 대안적으로, CSE-1이 CSE-2로부터 부정적인 응답을 얻은 경우, 이러한 부정적인 응답은 역할 이전에 실패했음을 나타낸다. 따라서, CSE-1은 SP에게 그 실패를 통보하여, SP가 새로운 CSP 프로세스를 초기화하도록 할 수 있으며, 이것은 이제 상세히 설명되는 사례 2에서 도해된 예와 동일할 수 있다.

예시적인 사례 2에서, 역할 프로파일에 표시된 백업 CSE가 없는 경우, CSE-1은 아래의 단계들(5 및 6)에서 설명되는 바와 같이 이 문제를 직접 보고할 수 있다. 일부 사례들에서는, 보안 관점에서, SP는 더 많은 권한과 신뢰성을 가질 수 있다. 5에서, CSE-1은 SP에게 더 이상 CPC로 작동할 수 없으며 역할 이전을 수행할 수 없다는 것을 통보한다. 따라서, SP는 적어도 하나의 CPC로부터 메시지를 수신할 수 있으며, 이 메시지는 CSE가 더 이상 CPC가 아닐 수 있음을 나타낸다. 이러한 메시지에 응답하여, 도 16 및 도 17과 관련하여 전술한 역할 할당 단계들 중 임의의 단계 또는 모든 단계들이 반복될 수 있다. 5에서의 메시지에는 CSE가 더 이상 CPC가 될 수 없다는 것을 SP에게 통보하는 값을 포함할 수 있는 메시지 유형(m_t) 데이터 필드가 포함될 수 있다. 6에서, SP는 이 통지에 대해 CSE-1에게 확인응답하고 새로운 CSP를 초기화한다. 따라서, 응답 메시지는 이 표시에 대한 응답 유형 필드(r_t)를 포함할 수 있다. 대안적인 방식(예를 들어, 사전 정의된 온 듀티 스케줄에 기반함)에 따라 다수의 상이한 CSE들이 CPC 역할을 수행하는 사례들에서, 본 명세서에서 설명되는 예시적인 역할 이전은 또한 복수의 CSE들 간에 CPC를 변경하는데 적용될 수 있다.

이제 CPM 할당으로 돌아가면, CPC로서 CSE를 할당하는 것과 관련하여 전술한 예시적인 방법들이 이용될 수 있다. 이러한 재이용은 개발 주기들을 단축하고, 특히 많은 M2M 노드들이 용량 제약을 받는다는 점을 고려할 때, M2M 노드에 배포될 수 있는 경량 코드 개발에 도움이 된다. 그러나, 일부 사례들에서, CPC 역할 할당과 CPM 역할 할당 간에 차이들이 있다. 예를 들어, 일부 사례들에서는 CPM 역할을 CSE에게 할당하는 것 뿐만 아니라 VNF 풀 아키텍처에서 정의된 역할들이 체계적인 방식으로 작업하기 위해 함께 연결될 수 있도록 CPM을 CPC와 연결하는 것이 필요할 수 있다. 따라서, 도 15 내지 도 18과 관련하여 설명된 예시적인 방법들은 CPM 할당에 재이용될 수 있으며, 관련된 역할들을 함께 연결하여 VNF 풀 아키텍처를 구축하기 위해 역할 연결 프로세스(Role Linking Process: RLP)가 또한 수행될 수 있다.

따라서, 일 예에 따르면, SP(또는 일반적으로 노드 또는 장치)는 복수의 공통 서비스 엔티티들에게 요청을 전송할 수 있다. 이 요청에 응답하여, SP는 복수의 공통 서비스 엔티티들로부터 복수의 응답들을 수신할 수 있다. 각각의 응답은 각각의 공통 서비스 엔티티(CSE)가 공통 서비스 기능(CSF) 풀 관리자(CPM)일 수 있는지 여부에 관한 정보를 포함할 수 있다. SP는 복수의 공통 서비스 엔티티들로부터 적어도 하나의 CPM을 선택하기 위해 각각의 응답으로부터의 정보를 평가할 수 있다. 일 예에서, 요청은 각각의 CSE의 현재 용량 및 각각의 CSE가 CPM이 되려고 하는지 여부를 질의한다. SP는 적어도 하나의 CPM에 대한 역할 프로파일을 생성할 수 있다. 역할 프로파일은 CPM의 가상 기계에 대한 최소 성능 요구사항, CPM의 가상 기계에 대한 선호 성능 시간, 역할 이전 전략 및 역할 소프트웨어 업데이트 스케줄 중 적어도 하나를 포함할 수 있다. 일 예에서, SP는 복수의 CSF 풀 관리자들을 선택할 수 있고, 역할 프로파일은 각각의 CSF 풀 관리자와 연관된 온 듀티 시간을 추가로 포함할 수 있다. SP는 복수의 공통 서비스 엔티티들 중 적어도 하나의 CSE에게 역할 프로파일을 전송할 수 있다. 역할 프로파일에 응답하여, SP는 적어도 하나의 CSE로부터 확인응답을 수신할 수 있고, 이 확인응답은 적어도 하나의 CSE가 역할 프로파일에 표시된 대로 그 가상 기계 리소스들을 예비하기 시작할 것임을 나타낼 수 있다. 일 예에서, SP는 소프트웨어 패키지를 적어도 하나의 CSE에 배포할 수 있으며, 이 패키지는 적어도 하나의 CSE가 그 자신을 CPM이 되도록 구성하게 할 수 있다. 다른 예에서, SP는 적어도 하나의 CSE에게 표시를 전송할 수 있으며, 이 표시는 적어도 하나의 CSE가 그 자신을 CPM이 되도록 구성하게 할 수 있다.

도 19를 참조하면, 도시된 RLP에 따라, SP는 전술한 절차들을 이용하여 CPC 역할을 CSE-1에게 이미 할당하였다. 이 예에서, SP는 유형-X CSF 인스턴스들에 대해 CPM 역할을 할당하려고 한다. 이를 수행하기 위해, 앞서 언급한 것처럼, 이전 CSP와 RAP를 재이용할 수 있으며, 예시적인 목적들을 위해 CSE-2가 유형-X CSF 인스턴스들에 대해 CPM 역할을 하는 것으로 가정한다.

일 예(사례 1)에서, CPM은 RLP를 완료하기 위해 사전에 CPC와 접촉한다. 도시된 바와 같이, 1에서, 역할 할당 후에, SP는 현재 CPC의 역할을 하고 있는 CSE(예를 들어, 이 사례에서는 CSE-1)에 관해 CSE-2에게 직접 통보할 수 있다. 따라서, CSE-2의 VPES는 역할 연결을 달성하기 위해 사전에 CPC(예를 들어, 이 사례에서는 CSE-1)와 접촉할 수 있다. 1에서 전송된 메시지는 예를 들어 그리고 제한 없이 다음과 같은 다양한 데이터 필드들을 포함할 수 있다:

발신자 ID(s_id): 메시지 발신자의 아이덴티티는 메시지가 SP에서 온 것임을 수신자에게 통보할 수 있다.

메시지 유형(m_t): 메시지 유형은 메시지의 목적을 나타낸다. 예를 들어, 메시지 유형에 기반하여, 수신자 CSE는 SP가 수신자 CSE에게 CPC의 아이덴티티를 통보하고 있음을 알 것이다.

CSE-CPC-ID(cse-cpc-id): 이 필드는 현재 CPC로 작동 중인 CSE-ID를 저장할 수 있다.

계속해서 도 19를 참조하면, 2에서, 도시된 예에 따라, CSE-2의 VPES는 CSE-1의 VPES와 접촉하고, CSE-1에게 CSE-2가 현재 유형-X CSF 인스턴스들에 대해 새로운 CPM으로 작동하고 있으며 CSF의 이 유형(유형-X)과 관련된 향후 요청들을 처리할 준비가 되었다는 것을 통보한다. 일부 사례들에서, 이 프로세스는 등록과 유사하며, 양 노드들이 서로를 알 수 있다. 3에서, CSE-1의 VPES는 통지를 수신하고 레지스트리 엔트리들을 파일에 기록하거나 CPC 소프트웨어가 CSE-2에서 실행 중인 CPM 소프트웨어와 대화할 수 있도록 CSE-1에 CPC 소프트웨어를 구성한다. 예를 들어, CPC와 CPM 간에 전송되는 메시지들, 및 CPC와 CPM들 간에 지원되는 영업 논리는 CPC 또는 CPM 소프트웨어 패키지들로 구현될 수 있다. 따라서, 일부 사례들에서는, 수행해야 할 것은 현재 누가 그 역할들을 맡고 있는지, 그리고 서로 어떻게 통신할 것인지(예를 들어, 통신들을 위한 그 IP 주소들 또는 포트 번호들 및 임의의 다른 접촉 지점 정보를 교환함)에 관한 누락 정보를 채우는 것이다. 4에서, CSE-1의 VPES는 이제 역할 연결을 완료하기 위해 CSE-2에 연결하고 있음을 확인응답(ack)한다. 이 시점에서, CPC의 역할을 하는 CSE-1과 CSF-x 유형 인스턴스에 대해 CPM 역할을 하는 CSE-2는 이제 서로 연결되어 VNF 풀 아키텍처에 정의된 대로 함께 작업할 수 있다. 이전 ack들과 유사하게, 4에서의 ack 메시지는 RLP 프로세스가 CPC에서 완료되는지 여부를 나타내는 응답 유형(r_t) 데이터 필드를 포함할 수 있다. 5에서, 도시된 예에 따라, CSE-2의 VPES는 또한 CPM 소프트웨어가 이제 CSE-1 상에서 실행되는 CPC 소프트웨어와 대화할 수 있도록 CSE-2 상에서 실행되는 CPM 소프트웨어를 구성하는 것이 필요할 수 있다.

이제 도 19에 도시된 다른 예(사례 2)로 돌아가면, CPC와 접촉하기 위해 CPM을 트리거링하는 대신에, SP는 또한 CPC가 역할 연결을 위해 새롭게 할당된/구성된 CPM과 사전에 접촉할 수 있도록 CPC에게 통보할 수 있다. 6에서, SP는 유형-X CSF 인스턴스에 대해 CPM의 역할을 맡을 CSE(예를 들어, 이 사례에서는 CSE-2)가 있음을 CSE-1에게 직접 통보할 수 있으며, 이에 따라 CSE-1의 VPES는 RLP를 달성하기 위해 사전에 CSE-2와 접촉할 수 있다. 따라서, SP는 CSF 풀 관리자인 다른 CSE의 아이덴티티를 적어도 하나의 CSE에게 통보할 수 있으며, 적어도 하나의 CSE는 CPM인 그 CSE와 접촉할 수 있다. 유사하게, SP는 CSF 풀 제어기(CPC)인 다른 CSE의 아이덴티티를 적어도 하나의 CSE에게 통보할 수 있으며, 적어도 하나의 CSE는 CPC인 그 CSE와 접촉할 수 있다. 6에서 전송된 메시지는 예로서 그리고 제한 없이 제시된 다음의 데이터 필드들을 포함할 수 있다:

메시지 유형(m_t): 메시지 유형은 메시지의 목적을 나타낸다. 예를 들어, 메시지 유형 데이터 필드에 기반하여, 수신자 CSE는 SP가 현재 새로운 CPM으로서 어떤 것이 작동하고 있는지를 수신자 CSE에게 전하고 있음을 알 것이다.

CSE-CPM-ID(cse-cpc-id): 이 필드는 현재 CPM으로서 작동하고 있는 CSE-ID를 저장할 수 있다.

CSF-Type-ID(csf-ty-id): 이 필드는 새로운 CPM에 의해 관리될 CSF 인스턴스들의 대응 유형을 저장할 수 있다.

7에서는, 3과 유사하게, CPC의 VPES는 SP로부터 직접 통지를 수신하고, 레지스트리 엔트리들을 파일에 기록하거나 CPC 소프트웨어를 구성한 다음에 CSE-2의 VPES와 사전에 접촉한다. 8에서는, 4와 유사하게, CSE-1은 CSE-2와 접촉하여 CSE-2가 이제 CPC로 작동하고 있음을 CSE-2에게 통보한다. 9에서는, 5와 유사하게, CSE-2의 VPES는 CSE-2에서 실행되는 CPM 소프트웨어를 구성하여 CPM 소프트웨어가 이제 RLP를 완료하기 위해 CSE-1에서 실행되는 CPC 소프트웨어와 대화할 수 있게 한다. 10에서는, 도시된 예에 따라, CSE-2는 RLP가 완료되었음을 확인응답한다.

이제 풀 관리로 돌아가면, CPM은 풀 관리를 수행할 수 있다. 특히, 상이한 CSE들의 CSF 소프트웨어 인스턴스들은 논리적 VNF 풀에 합류하거나 나갈 수 있으며 대응 CPM들에 의해 관리될 수 있다.

도 20을 참조하면, 도시된 예에 따라, CSF 소프트웨어 인스턴스는 CPM에 의해 관리되는 대응 VNF 풀에 합류한다. 도 20에 도시된 바와 같이, CSE-1은 CPC로서 작동하고, CSE-2는 유형-X CSF 인스턴스들에 대해 CPM으로서 작동하며, CSE-3은 그 VM 상에서 실행되는 유형-X CSF 소프트웨어 인스턴스를 갖는다. 따라서, 이 예에 따라, VNF 풀 기반 서비스 계층이 생성되었고, 특정 역할들이 네트워크의 CSE들에게 할당되었다. 도 20에 도시된 예에서, CPC는 VNF 풀 기반 시스템의 포털이며, 네트워크 내의 CSE들이 CPC의 존재를 알고 있다고 가정한다. 또한, CSE-3에서 실행되는 유형-X CSF 인스턴스가 있으며, 그 영업 논리에 따라 이 CSF 인스턴스가 VNF 풀에 참여하려고 하고 CPM에 의해 관리된다고 가정한다. 그렇게 하기 위해, CSE-3은 현재 CSE-1인 CPC와 접촉하려고 시도한다. 대안적으로, CPM은 상이한 CSE들과 접촉하여 이들이 대응 CSF 인스턴스들을 호스팅하거나 실행시키는지 여부, 및 이들이 대응 VNF 풀들에 합류하려고 하는지 여부를 물어볼 수 있다.

계속해서 도 20을 참조하면, 1에서, 도시된 실시예에 따라, CSE-3은 하나 이상의 VNF 풀에 합류하려고 하는 CSE-3에서 실행되는 CSF 인스턴스들(예를 들어, 도시된 바와 같이 CSE-3에서 실행되는 유형-X CSF 인스턴스)을 포함하는 CSF 인스턴스 리스트와 함께 요청을 CSE-1에게 전송한다. 이 요청은 CSE-3이 특정 유형의 풀에 합류하려고 하는 특정 유형의 하나 이상의 CSF 인스턴스를 포함한다는 것을 나타낼 수 있다. 1에서의 메시지는 예로서 그리고 제한 없이 제시된 다음의 데이터 필드들을 포함할 수 있다:

발신자 ID(s_id): 메시지 발신자의 아이덴티티는 메시지가 CSE에서 온 것임을 수신자에게 통보한다.

메시지 유형(m_t): 메시지 유형은 이 메시지의 목적을 나타낸다. 예를 들어, 메시지 유형으로부터, CPC는 발신자가 VNF 풀들에 합류하려고 하는 일괄 CSF 인스턴스들을 전송하고 있음을 알 것이다.

CSF-instance-list(cse-cpc-id): 이 필드는 VNF 풀에 합류하려고 하는 각각의 CSF 인스턴스에 관한 세부 정보를 저장한다. 이 정보는 그 CSF 유형, 액세스 지점 등을 포함할 수 있다.

따라서, CPC는 공통 서비스 엔티티(CSE)로부터 요청을 수신할 수 있으며, 이 요청은 CSE가 특정 유형의 풀에 합류하려고 하는 특정 유형의 하나 이상의 공통 서비스 기능(CSF) 인스턴스를 포함한다는 것을 나타낼 수 있다.

2에서, CPC는 어떤 CPM들(예를 들어, 도시된 바와 같이 CSE-2에 의해 취해진 유형-X CSF 인스턴스에 대한 CPM)이 통보되어야 하는지를 알기 위해 그 레지스트리 리스트를 체크한다. 따라서, CPC는 레지스트리 리스트로부터 요청을 통보 받아야 하는 하나 이상의 CSF 풀 관리자를 결정할 수 있으며, 하나 이상의 관리자는 특정 유형의 각각의 풀과 연관된다. 또한, 일부 사례들에서, 주어진 유형의 CSF에 대해, CSE에 할당된 CPM 역할이 없을 수 있다. 이 사례에서, CPC는 이 합류-풀 요청을 직접 거절할 수 있다. 3에서, 도시된 예에 따라, CPC는 CSE-3에서 실행되는 유형-X CSF 인스턴스가 이제 유형-X CSF에 대한 VNF 풀에 합류하려고 신청하고 있다는 통지를 CSE-2에게 전송한다. 3에서의 메시지는 예로서 그리고 제한 없이 제시된 다음의 데이터 필드들을 포함할 수 있다:

발신자 ID(s_id): 메시지 발신자의 아이덴티티는 메시지가 CPC에서 온 것임을 수신자에게 통보한다.

메시지 유형(m_t): 메시지 유형은 이 메시지의 목적을 나타낸다. 예를 들어, 메시지 유형에 기반하여, CPM은 그 풀에 합류하길 원하는 새로운 CSF 인스턴스들이 있음을 알 것이다.

CSF-instance-list(cse-cpc-id): 이 필드는 현재 CPM에 의해 관리되는 VNF 풀에 합류하려고 하는 각각의 CSF 인스턴스에 관한 세부 정보를 저장한다. 이 정보는 예를 들어 그 CSF 유형, 액세스 지점 등을 포함할 수 있다.

따라서, CPC는 하나 이상의 CSF 풀 관리자들 중 적어도 하나에게 통지를 전송할 수 있으며, 이 통지는 CSE의 하나 이상의 인스턴스가 적어도 하나의 CSF 풀 관리자에 의해 관리되는 각각의 풀에 합류하려고 신청하고 있음을 나타낼 수 있다.

계속해서 도 20을 참조하면, 4에서, 도시된 예에 따라, CSE-2는 유형-X CSF에 대한 VNF 풀의 CPM으로서 현재 작동하고 있으며, CSE-2는 이 CSF 인스턴스가 풀에 합류할 수 있음을 승인한다. CSE-2는 또한 이 인스턴스를 향후 이용(예를 들어, 프로비저닝)을 위해 인벤토리 리스트 또는 스케줄링 계획에 추가한다. 따라서, CSF 인스턴스들이 풀에 합류하도록 승인되면, CSF 인스턴스들은 향후 이용을 위해 인벤토리 리스트에 추가될 수 있다. 5에서, CSE-2는 또한 CSE-3에게 그 유형-X CSF 인스턴스가 이제 CPM인 CSE-2에 의해 관리됨을 통보한다. 따라서, 전송된 요청에 기반하여, CSE-3은 CPM으로부터 전송된 메시지를 수신할 수 있으며, 이 메시지는 하나 이상의 CSF 인스턴스가 CPM에 의해 관리되고 있음을 나타낼 수 있다. 6에서, CSE-3은 이 승인 통지를 확인응답하고 또한 CSE-3과 연관된 성능 데이터를 그 능력 사양으로서 CSE-2에게 전송한다. CSE-3은 CSE-3과 연관된 성능 데이터를 포함하는 ack 메시지를 전송할 수 있다. 5에서의 ack 메시지는 예로서 그리고 제한 없이 제시된 다음의 데이터 필드들을 포함할 수 있다:

응답 유형(r_t): 이 데이터 필드는 발신자 CSE에서 실행되는 CSF 인스턴스가 CPM에 의해 관리될 준비가 되었음을 나타낸다.

성능 데이터(p_d): 이 데이터 필드는 또한 일부 기본 성능 데이터를 포함할 수 있으며, CPM은 나중에 이 데이터를 이용하여 CSF 인스턴스를 선택할 수 있다.

7에서, CSE-2는 인벤토리 리스트를 업데이트하여 기본 성능 데이터를 추가할 수 있다. 예를 들어 CPM이 특정 서비스 계층 요청들을 처리하기 위해 이 CSF 인스턴스를 할당하거나 호출하려는 경우 이 데이터를 참조로 이용할 수 있다.

이제 도 21을 참조하면, CSF 소프트웨어 인스턴스는 예시적인 실시예에 따라 풀에서 나간다. 도 21에 도시된 바와 같이, CSE-2는 유형-X CSF 인스턴스들에 대한 CPM으로서 작동하고 있고, CSE-3은 실행되는 유형-X CSF 인스턴스를 가지며, CSE-3은 CPM(이 예에서는 CSE-2)에 의해 관리되는 VNF 풀에 있다.

제1 예(사례 1)에서, CPM은 풀 인스턴스를 풀로부터 삭제하는 것을 개시한다. 예를 들어, CSE-2는 이력 성능 통계치(또는 임의의 다른 이유)에 기반하여 CSE-3에서 실행되는 유형-X CSF 인스턴스가 항상 바람직한 성능을 전달할 수는 없다고 결정할 수 있다. 따라서, CSE-2는 이 멤버를 풀에서 삭제하도록 결정할 수 있으며 또한 이 멤버를 나중에 풀 멤버로서 선택하지 않을 수 있다. 다른 원인들이 CPM을 트리거링하여 풀 인스턴스를 삭제할 수 있음을 이해할 것이다.

1에서, 도시된 예에 따라, CSE-2는 CSE-3에서 실행되는 유형-X CSF 인스턴스가 풀에서 삭제될 것이라는 통지를 CSE-3에게 직접 전송한다. 1에서의 메시지는 예로서 그리고 제한 없이 제시된 다음의 데이터 필드들을 포함할 수 있다:

발신자 ID(s_id): 메시지 발신자의 아이덴티티는 메시지가 CPM에서 온 것임을 수신자에게 통보한다.

메시지 유형(m_t): 메시지 유형은 이 메시지의 목적을 나타낸다. 예를 들어, 메시지 유형에 기반하여, 수신자 CSE는 이 메시지가 실행되는 CSF 인스턴스의 삭제에 관한 통지임을 알 것이다.

CSF-instance-list(cse-cpc-id): 이 필드는 수신자 CSE에서 실행되는 어떤 CSF 인스턴스들이 풀에서 삭제될지를 저장한다.

따라서, CSE-2는 CSE-3에게 삭제 통지를 전송할 수 있으며, 이 삭제 통지는 하나 이상의 CSF 인스턴스가 풀에서 삭제되고 있음을 나타낼 수 있다. 일 예에서, 삭제 통지는 CSE-3의 하나 이상의 이력 성능 특성에 기반하여 전송될 수 있다. 2에서, CSE-3은 통지를 수신하고 (필요한 경우) 관련 구성을 수행할 수 있다. 3에서, CSE-3은 CSE-2에게 실행되는 유형-X CSF 인스턴스가 CPM에 의해 관리되지 않을 것임을 확인응답한다. 3에서의 확인응답(ack) 메시지는 응답 유형(r_t) 데이터 필드를 포함할 수 있으며, 이는 수신자 CSE가 실행되는 CSF 인스턴스들 중 하나 이상이 풀에서 삭제될 것이라는 사실을 이미 인식하고 있음을 나타낼 수 있다. 따라서, CSE-2는 CSE-3으로부터 삭제 확인응답을 수신할 수 있고, 이 삭제 확인응답은 하나 이상의 CSF 인스턴스가 풀에서 삭제되고 있다는 것을 CSE-3이 인식하고 있음을 나타낼 수 있다. 일부 사례들에서, CSF 인스턴스가 풀에서 나가면, 그 CSF 인스턴스에 의해 처리되고 있는 진행 중인 작업들이 있을 수 있다. 일 예에서, CSF 인스턴스는 진행 중인 모든 작업들을 완료할 때까지 풀에서 나갈 수 없다. 다른 예에서, 이전이 수행된다.

계속해서 도 21을 참조하면, 제2 예(사례 2)에서, 특정 CSF 인스턴스는 VNF 풀에서 나가도록 사전에 제안한다. 예를 들어, 도시된 바와 같이, CSE-3은 실행되는 유형-X CSF 인스턴스가 그 CPM에 의해 할당된 요청 처리를 지원할 수 없다고 결정한다. 따라서, 삭제 통지는 CSF 인스턴스들이 그 할당된 처리를 지원할 수 없다는 CSE-2의 결정에 기반하여 전송될 수 있다. 이 결정은 다양한 이유들, 예컨대 소프트웨어 문제 또는 이용가능한 저전력에 기반하여 행해질 수 있다. 따라서, CSE-3은 CSE-2가 관리하는 대응 VNF 풀에서 나가기로 결정한다. 4에서, 도시된 예에 따라, CSE-3은 실행되는 유형-X CSF 인스턴스가 풀에서 나가도록 요청하고 있음을 나타내기 위해 CSE-2에게 직접 통지를 전송한다. 4에서 전송된 메시지는 예로서 그리고 제한 없이 제시된 다음의 데이터 필드들을 포함할 수 있다:

메시지 유형(m_t): 메시지 유형은 메시지의 목적을 나타낸다. 예를 들어, 메시지 유형에 기반하여, CPM은 발신자 CSE에서 실행되는 CSF 인스턴스가 풀에서 나가도록 요청하고 있음을 알 것이다.

CSF-instance-list(cse-cpc-id): 이 필드는 수신자 CSE에서 실행되는 어떤 CSF 인스턴스들이 풀에서 나갈지를 저장한다.

5에서, 도시된 예에 따라, CSE-2는 통지를 수신하고 (필요한 경우) 관련 구성을 수행할 수 있다. CSE-2는 또한 이 CPM의 멤버 인벤토리에서 이 CSF 인스턴스를 삭제할 수 있다. 6에서, CSE-2는 CSE-3에게 실행되는 유형-X CSF 인스턴스가 더 이상 풀에 없음을 확인응답한다. 6에서의 ack 메시지는 응답 유형(r_t) 데이터 필드를 포함할 수 있으며, 이는 그 CSF 인스턴스들이 대응 CPM에 의해 풀에서 성공적으로 삭제되었는지 여부를 나타낼 수 있다.

전술한 바와 같이, 본 명세서에 개시된 실시예들은 oneM2M 기능적 아키텍처로 구현될 수 있지만, M2M 서비스 계층을 넘어서 또한 적용될 수 있다. 예를 들어, 전술한 바와 같이, NFV 기술은 서비스 계층을 넘어서는 작업들(예를 들어, 도 15 참조)을 포함하는 VNF 풀 기반 서비스 계층을 구축하도록 구현될 수 있다. 예를 들어, CSF 인스턴스들은 NFV에서 고려되는 네트워크 기능 소프트웨어 인스턴스들일 수 있다. 특히, oneM2M에 의해 정의된 기존의 CSF들은 M2M 노드들의 VM들에서 실행되는 소프트웨어 인스턴스들로서 구현되는 것으로 가정한다. 따라서, 전술한 방법들은 SP에 의한 시스템 설정과 관련될 수 있으며, 이는 M2M 서비스 계층의 범위를 넘는 것으로 고려될 수 있음을 알 것이다.

일 예에서, 본 명세서에서 설명되는 방법들을 구현함으로써, CPC 또는 CPM 소프트웨어는 CSE들이 CPC 또는 CPM으로서 작동할 수 있도록 CSE들 상에 배포될 수 있다. 따라서, CSE에 의해 수신되는 서비스 계층 요청 메시지는 수신자 CSE 자체에 의해 처리될 필요 없이 처리를 위해 CPC 또는 CPM으로 추가로 전송될 수 있다. 따라서, 수신자 CSE가 수신된 서비스 계층 요청 메시지를 처리하기 위해 (CPC로서 작동하는) 다른 CSE와 접촉할 수 있기 때문에, 본 명세서에서 설명되는 실시예들은 기존의 mca 및 mcc 기준점들에게 영향을 줄 수 있다. 또한, 전술한 바와 같이, VPES가 이용될 수 있고, 이에 따라 VPES는 도 22에 도시된 예시적인 실시예에 따라 서비스 계층에서 새로운 CSF로서 정의된다.

이제 도 23 및 도 24를 참조하면, 전술한 바와 같이 VNF 풀 기반 요청 처리를 지원하는 새로운 oneM2M 리소스들이 정의된다. 특히, VNF 풀 아키텍처에 정의된 상이한 역할들 및 이러한 역할들을 맡을 수 있는 상이한 CSE들이 있기 때문에, <CPC> 리소스(도 23 참조) 및 <CPM> 리소스(도 24 참조)는 예시적인 실시예에 따라 정의된다. CPC 및 CPM의 리소스 속성들에 대한 설명들은 아래의 표 2 및 표 3에서 각각 제시된다.

본 명세서에서 정의된 oneM2M 리소스들(도 23 및 도 24 참조)은 전술한 풀 기반 서비스 계층에 의해 지원되는 새로운 요청 처리 패러다임을 실현할 수 있다. 예를 들어, CSE는 발신자로부터 요청을 수신하면 CSE(예를 들어, CPC로서 현재 작동하는 CSE) 상에 호스팅된 <CPC> 리소스의 URI로 이 요청을 직접 전달함으로써 VNF 풀들에서의 CSF 인스턴스들을 이용하여 이 요청을 처리할 수 있다. 따라서, 일부 사례들에서, 요청이 <CPC> 리소스를 목표로 하면, CPC로서 작동하는 호스팅 CSE는 이 요청이 VNF 풀 패러다임에 따라 처리될 것임을 알 것이다. 다음으로, CPC는 이 요청을 처리하기 위해 어떤 CPM들을 접촉해야 하는지를 결정할 수 있으며, 대응 <CPM> 리소스들을 목표로 하는 요청을 전달할 수 있다. 마찬가지로, CPM으로서 작동하는 CSE는 요청 메시지를 수신하면 그 <poolMemberList>로부터 적합한 CSF 인스턴스들을 찾아서 풀에서의 특정 CSF 인스턴스들이 그 요청을 처리하고 결과를 회신하게 할 수 있다.

<표 2>

<표 3>

이제 도 25를 참조하면, 도 23 및 도 24에 도시된 oneM2M 리소스들이 개시된 풀 기반 서비스 계층을 실현하는데 이용되는 방법의 예가 도시되어 있다. 이 예시적인 방법은 M2M SP, M2M 서버, 복수의 M2M 게이트웨이들(GW들) 및 복수의 M2M 디바이스들을 포함하는 시스템(또는 네트워크)에서 수행된다. M2M 게이트웨이들은 서비스 계층(SL) 및 SL 상의 VPES를 호스팅하는 M2M GW#1, 및 SL 및 SL 상의 VPES를 호스팅하는 M2M GW#2를 포함한다. M2M 디바이스들은 SL 및 SL 상의 VPES를 호스팅하는 M2M 디바이스#1, 및 SL을 호스팅하는 M2M 디바이스#2를 포함한다. 도 25의 예시적인 시스템은 개시된 주제의 설명을 용이하게 하기 위해 간략화된 것이며, 본 개시내용의 범위를 제한하려는 의도가 아니라는 것을 이해할 것이다. 다른 디바이스들, 시스템들 및 구성들은 도 25에 도시된 네트워크와 같은 시스템에 추가하여 또는 그 대신에 본 명세서에 개시된 실시예들을 구현하는데 이용될 수 있으며, 이러한 모든 실시예들은 본 개시내용의 범위 내인 것으로 고려된다.

이 예에서, 제1 단계는 SP가 CPC 역할을 M2M 서버에 할당하는 것을 포함한다. 001에서, 도시된 예에 따라, CPC 할당을 위한 작업이 수행되고, M2M 서버가 CPC로서 작동하도록 선택된다. 002a에서, SP는 M2M 서버에 대해 <CPC> 리소스를 생성하도록 결정하고, 요청 메시지는 생성 <svrCSEBase>/<CPC1>로 기술된다. M2M 서버는 요청을 수신한 후에 <CPC1> 리소스를 생성할 수 있다. 일부 사례들에서, 특정 CPM 역할들이 시스템의 다른 CSE들(예를 들어, M2M GW#1)에 할당되면 나중에 이들은 전술한 RLP를 이용하여 CPC와 연결될 것이다. 또한, M2M 서버는 CPC로서 작동하기 시작하면 네트워크의 다른 CSE들에게 이러한 정보(예를 들어, <CPC1> 리소스의 존재)를 사전에 방송할 수 있으며, <CPC1> 리소스는 기존의 IETF VNF 풀 기준 아키텍처에 정의된 대로 서비스 포털로 간주될 수 있다. 대안적으로, 다른 CSE들은 oneM2M에 정의된 기존의 리소스 발견 접근 방식을 이용하여 <CPC1> 리소스를 발견하도록 선택할 수 있다.

계속해서 도 25를 참조하면, 002b에서, 도시된 예에 따라, M2M 서버는 생성 응답(위치 = <svcCSEBase/<CPC1>)으로 기술되는 응답을 다시 전송한다. 도시된 바와 같이, CPM 역할이 GW#1에 할당된다. 003에서, CPM 할당 작업이 수행되고, GW#1이 CSF를 압축하는 데이터에 대해 CPM으로서 작동하도록 선택된다. 004a에서, SP는 GW#1에서 <CPM> 리소스를 생성하도록 결정하고, 요청 메시지는 생성 <gw1CSEBase>/<CPM1>로 기술된다. M2M GW#1은 요청을 수신한 후에 <CPM1> 리소스를 생성할 수 있다. 004b에서, 생성 응답(위치 = <gw1CSEBase/<CPM1>) 메시지가 SP에 설정된다. GW#1은 CPM의 역할을 맡은 후에 풀 관리를 수행하기 시작할 것이다. 예를 들어, 005에서, 도시된 바와 같이, GW#1은 CSF를 압축하는 데이터에 대한 풀 관리를 수행하고, 디바이스#1 및 다른 디바이스들(본 명세서에서는 도시되지 않음) 상의 이러한 CSF 인스턴스는 풀에 합류하려고 한다. 006에서, 단계(001)에서 전술한 바와 같이 oneM2M에 정의된 기존의 리소스 발견 접근 방식을 이용하여 <CPC1> 리소스를 이미 발견할 수 있는 GW#2는 어떤 CSF 인스턴스들이 다양한 CSF 풀들에서 제공될 수 있는지를 협의함으로써 CPC와 접촉한다. CPC는 데이터 압축이 이용가능하다는 것을 GW#2에게 표시한 후 GW#2를 트리거링하여 CSF를 압축하는 데이터에 대응하는 <datacompressing1>로 불리는 리소스를 생성할 수 있다. 일부 사례들에서, 이러한 리소스는 임의의 리소스 표현을 포함하지 않는다는 점에서 가상 리소스일 수 있다. 도시된 예에서, 이 리소스의 URI는 <gw2CSEBase>/<datacompressing1>이다.

계속해서 도 25를 참조하면, 도시된 예에 따라, 007에서, 디바이스#2는 이제 감지된 이미지를 갖고 이를 압축하기를 원하므로, 액세스 요청을 M2M GW#2 상의 <datacompressing1> 리소스에 전송한다. 예로서, 업데이트 동작이 수행될 수 있다. 008a에서, 요청 메시지는 업데이트 <gw2CSEBase>/<datacompressing1>로 기술되며, 이미지 데이터는 또한 페이로드에 포함된다. 009에서, 도시된 예에 따르면, GW#2는 이 요청을 처리할 능력을 갖지 않는다. 한편, 이러한 요청이 가상 리소스 <datacompressing1>을 목표로 하기 때문에, GW#2는 이 요청이 본 명세서에서 설명되는 풀링 방식으로 처리되어야 할 필요가 있음을 알 수 있다. 따라서, 현재 CPC(도시된 바와 같은 M2M 서버)로서 작동하고 있는 CSE에게 서비스 요청을 전송함으로써 전술한 풀 기반 서비스 계층 메커니즘들을 이용하기 시작할 것이다. 일부 사례들에서, 주소지정된 URI는 CPC 리소스일 것이며, M2M 서버는 이 요청이 풀 기반 서비스 계층 패러다임에 의해 처리될 것임을 알 것이다. 010a에서, 요청 메시지는 업데이트 <svcCSEBase/<CPC1>로 기술된다. 이 메시지는 또한 페이로드에서의 이미지 데이터 및 이 요청을 처리하는데 어떤 CSF 인스턴스들이 필요한지를 포함할 수 있다. 011에서, M2M 서버는 그 요청을 도시된 예에서 M2M GW#1인 대응 CPM에게 전달한다. 012a에서, 대응 메시지는 업데이트 <gw1CSEBase/<CPM1>로 기술되며, 이미지 데이터는 페이로드에 포함된다. GW#1은 요청을 수신하면 그 요청을 처리하기 위해 디바이스#1에서 CSF 인스턴스를 선택할 수 있다. 012b에서, 도시된 예에 따라, 응답 메시지가 전송되고, 압축된 데이터가 페이로드에 포함된다. 010b에서, (예를 들어, 단계(010a)에서 요청 메시지를 에코하기 위해) 업데이트 응답이 전송될 수 있다. 유사하게, 008b에서, (단계(008a)에서 요청 메시지를 에코하기 위해) 업데이트 응답이 전송된다.

이제 도 26을 참조하면, 예시적인 그래픽 사용자 인터페이스(GUI)가 도시되어 있다. 전술한 바와 같이, SP는 본 명세서에서 정의된 역할들을 할당할 책임이 있기 때문에, GUI는 SP가 상이한 역할들을 수행할 때 상이한 CSE들의 실시간 상태들을 모니터링할 수 있게 한다. 도 26은 SP가 상이한 역할들의 실시간 상태를 질의할 수 있는 전체 시스템 뷰에 대한 예시적인 GUI를 도시한다. 예를 들어, SP는 그 기본 성능, 얼마나 많은 CPM들이 시스템에서 이용가능한지, 주어진 CPM이 얼마나 많은 CSF 인스턴스들을 현재 관리하고 있는지 등을 결정하기 위해 CPC로서 현재 작동하고 있는 CSE에게 질의할 수 있다. GUI는 원하는 경우 대안적인 파라미터들을 모니터링하고 질의하는데 이용될 수 있다는 것을 이해할 것이다. 일부 사례들에서, 질의들은 SP가 네트워크에 대한 시스템 뷰를 가질 수 있도록 GUI에 문자열들로 입력될 수 있다.

이제 도 27을 참조하면, 단일 CSF 풀을 모니터링하기 위한 예시적인 GUI가 도시되어 있다. 도시된 바와 같이, 이 GUI를 이용하여, SP는 현재 얼마나 많은 CSF 인스턴스들이 풀에 있는지, 누가 이들 CSF 인스턴스들을 이용하고 있는지, 및 이들 CSF 풀 인스턴스들이 어디에서 왔는지(예를 들어, 어떤 CSE들로부터 왔는지)를 체크하거나 결정할 수 있다. 이러한 모니터링의 예들은 전부가 아니며, SP는 원하는 대로 GUI를 이용하여 다른 결정들 또는 검증들을 할 수 있음을 이해할 것이다. 따라서, GUI들은 사용자가 다양한 차트들 또는 대안적인 시각적인 묘사들을 통해 관심 있는 다양한 정보를 사용자에게 제공할 수 있다는 것을 또한 이해할 것이다.

도 13 내지 도 27 및 그에 관련된 설명은 풀 기반 서비스 계층들을 구축하기 위한 방법들 및 장치들의 다양한 실시예들을 도시한다. 이들 도면들, 특히 도 15 내지 도 21 및 도 25에서, 다양한 단계들 또는 동작들은 하나 이상의 노드, 디바이스, 기능 또는 네트워크에 의해 수행되는 것으로 도시되어 있다. 이러한 도면들에 도시된 노드들, 디바이스들, 기능들 또는 네트워크들은 통신 네트워크에서의 논리 엔티티들을 나타낼 수 있으며, 후술하는 도 28a 또는 도 28b에 도시된 일반적인 아키텍처들 중 하나를 포함할 수 있는 네트워크 노드의 메모리에 저장되고 그 프로세서 상에서 실행되는 소프트웨어(예를 들어, 컴퓨터 실행가능한 명령어들)의 형태로 구현될 수 있음을 알 것이다. 즉, 도 15 내지 도 21 및 도 25에 도시된 방법들은 예를 들어 도 28c 또는 도 28d에 도시된 노드 또는 컴퓨터 시스템과 같은 네트워크 노드 또는 장치의 메모리에 저장된 소프트웨어(즉, 컴퓨터 실행가능한 명령어들)의 형태로 구현될 수 있으며, 컴퓨터 실행가능한 명령어들은, 노드의 프로세서에 의해 실행될 때, 도면들에 도시된 단계들을 수행한다. 또한, 이들 도면들에 도시된 임의의 전송 및 수신 단계들은 노드의 프로세서의 제어하에 노드의 통신 회로(예를 들어, 도 28c 및 도 28d의 회로(34 또는 97)), 및 노드가 실행하는 컴퓨터 실행가능한 명령어들(예를 들어, 소프트웨어)에 의해 수행될 수 있는 것으로 이해된다.

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

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

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

도 28a에 도시된 바와 같이, M2M/IoT/WoT 통신 시스템(10)은 인프라스트럭처 도메인 및 필드 도메인을 포함할 수 있다. 인프라스트럭처 도메인은 종단간 M2M 배포의 네트워크 측을 지칭하고, 필드 도메인은 보통 M2M 게이트웨이 후방에 있는 영역 네트워크들을 지칭한다. 필드 도메인 및 인프라스트럭처 도메인 둘 다는 각종의 상이한 노드들(예를 들어, 네트워크의 서버들, 게이트웨이들, 디바이스들)을 포함할 수 있다. 예를 들어, 필드 도메인은 M2M 게이트웨이들(14) 및 단말 디바이스들(18)을 포함할 수 있다. 임의의 수의 M2M 게이트웨이 디바이스들(14)과 M2M 단말 디바이스들(18)이 원하는 대로 M2M/IoT/WoT 통신 시스템(10)에 포함될 수 있다는 점이 이해될 것이다. M2M 게이트웨이 디바이스들(14) 및 M2M 단말 디바이스들(18) 각각은 통신 네트워크(12) 또는 직접 무선 연결을 통해 신호들을 전송 및 수신하도록 구성되어 있다. M2M 게이트웨이 디바이스(14)는 무선 M2M 디바이스들(예를 들어, 셀룰러 및 비셀룰러)은 물론 고정 네트워크 M2M 디바이스들(예를 들어, PLC)이 통신 네트워크(12)와 같은 오퍼레이터 네트워크들 또는 직접 무선 연결 중 어느 하나를 통해 통신할 수 있게 한다. 예를 들어, M2M 디바이스들(18)은 데이터를 수집할 수 있고, 데이터를 통신 네트워크(12) 또는 직접 무선 연결을 통해 M2M 애플리케이션(20) 또는 M2M 디바이스들(18)에 전송할 수 있다. M2M 디바이스들(18)은 또한 M2M 애플리케이션(20) 또는 M2M 디바이스(18)로부터 데이터를 수신할 수 있다. 또한, 데이터 및 신호들은 이하 설명되는 바와 같이 M2M 서비스 계층(22)을 통해 M2M 애플리케이션(20)에 전송될 수 있고 그로부터 수신될 수 있다. M2M 디바이스들(18) 및 게이트웨이들(14)은, 예를 들어 셀룰러, WLAN, WPAN(예를 들어, 지그비, 6LoWPAN, 블루투스), 직접 무선 연결, 및 유선을 포함하는 다양한 네트워크들을 통해 통신할 수 있다. 예시적인 M2M 디바이스들은 태블릿들, 스마트폰들, 의료 디바이스들, 온도 및 날씨 모니터들, 커넥티드 카(connected car)들, 스마트 미터(smart meter)들, 게임 콘솔들, PDA들, 건강 및 피트니스 모니터들, 전등들, 서모스탯들, 가전기기들, 차고문들 및 다른 액추에이터 기반 디바이스들, 보안 디바이스들, 및 스마트 아웃렛들을 포함하지만, 이들에 제한되지는 않는다.

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

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

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

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

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

또한, 본 명세서에서 설명되는 방법들 및 기능들은 예를 들어 전술한 네트워크 및 애플리케이션 관리 서비스와 같은 서비스들에 액세스하기 위해 서비스 지향 아키텍처(SOA) 및/또는 리소스 지향 아키텍처(ROA)를 이용하는 M2M 네트워크의 일부로서 구현될 수 있다.

도 28c는, 도 14, 도 22, 도 28a 또는 도 28b에 도시된 것과 같은 M2M 네트워크에서 M2M 서버, 게이트웨이, 디바이스 또는 다른 노드로서 동작할 수 있는, 도 13, 도 15 내지 도 21 및 도 25에 도시된 노드들, 디바이스들 또는 기능들 중 하나와 같은 네트워크의 노드의 예시적인 하드웨어/소프트웨어 아키텍처의 블록도이다. 도 28c에 도시된 바와 같이, 노드(30)는 프로세서(32), 트랜시버(34), 전송/수신 요소(36), 스피커/마이크로폰(38), 키패드(40), 디스플레이/터치패드(42), 비이동식 메모리(44), 이동식 메모리(46), 전원(48), 글로벌 포지셔닝 시스템(GPS) 칩셋(50), 및 다른 주변기기들(52)을 포함할 수 있다. 노드(30)는 또한 트랜시버(34) 및 전송/수신 요소(36)와 같은 통신 회로를 포함할 수 있다. 노드(30)가 일 실시예와 부합한 채로 있으면서 전술한 요소들의 임의의 하위 조합을 포함할 수 있다는 것을 이해할 것이다. 이 노드는 예를 들어 도 13, 도 15 내지 도 21 및 도 25에서 설명된 방법들, 또는 도 23 및 도 24, 표 1 내지 표 3 또는 청구항에서의 데이터 구조들과 관련하여 풀 기반 M2M 서비스 계층의 구축을 구현하는 노드일 수 있다.

프로세서(32)는 범용 프로세서, 특수 목적 프로세서, 통상의 프로세서, DSP(digital signal processor), 복수의 마이크로프로세서들, DSP 코어, 제어기, 마이크로제어기, ASIC들(Application Specific Integrated Circuits), FPGA(Field Programmable Gate Array) 회로들, 임의의 다른 유형의 IC(integrated circuit), 상태 기계과 관련되는 하나 이상의 마이크로프로세서 등일 수 있다. 프로세서(32)는 신호 코딩, 데이터 처리, 전력 제어, 입력/출력 처리, 및/또는 노드(30)가 무선 환경에서 동작할 수 있게 하는 임의의 다른 기능을 수행할 수 있다. 프로세서(32)는 트랜시버(34)에 결합될 수 있고, 이는 전송/수신 요소(36)에 결합될 수 있다. 도 28c가 프로세서(32)와 트랜시버(34)를 별도의 구성요소들로서 묘사하고 있지만, 프로세서(32)와 트랜시버(34)는 전자 패키지 또는 칩 내에 함께 통합될 수 있다는 것을 이해할 것이다. 프로세서(32)는 애플리케이션 계층 프로그램들(예를 들어, 브라우저들) 및/또는 RAN(radio access-layer) 프로그램들 및/또는 통신들을 수행할 수 있다. 프로세서(32)는 예를 들어, 액세스 계층 및/또는 애플리케이션 계층 등에서 인증, 보안 키 일치(security key agreement), 및/또는 암호 동작들과 같은 보안 동작들을 수행할 수 있다.

도 28c에 도시된 바와 같이, 프로세서(32)는 그 통신 회로(예를 들어, 트랜시버(34) 및 전송/수신 요소(36))에 결합된다. 프로세서(32)는, 컴퓨터 실행가능한 명령어들의 실행을 통해, 노드(30)로 하여금 그에 접속되어 있는 네트워크를 통해 다른 노드들과 통신하게 하기 위해 통신 회로를 제어할 수 있다. 특히, 프로세서(32)는 본 명세서(예를 들어, 도 15 내지 도 22 및 도 25) 및 청구항들에서 설명되는 전송 및 수신 단계들을 수행하기 위해 통신 회로를 제어할 수 있다. 도 28c가 프로세서(32)와 트랜시버(34)를 별도의 구성요소들로서 묘사하고 있지만, 프로세서(32)와 트랜시버(34)는 전자 패키지 또는 칩 내에 함께 통합될 수 있다는 것을 이해할 것이다.

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

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

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

프로세서(32)는 비이동식 메모리(44) 및/또는 이동식 메모리(46)와 같은 임의의 유형의 적합한 메모리로부터의 정보에 액세스하거나 그 메모리에 데이터를 저장할 수 있다. 비이동식 메모리(44)는 RAM, ROM, 하드 디스크, 또는 임의의 다른 유형의 메모리 저장 디바이스를 포함할 수 있다. 이동식 메모리(46)는 SIM(subscriber identity module) 카드, 메모리 스틱, SD(secure digital) 메모리 카드 등을 포함할 수 있다. 다른 실시예들에서, 프로세서(32)는, 서버 또는 홈 컴퓨터와 같은, 노드(30) 상에 물리적으로 위치되지 않은 메모리로부터의 정보에 액세스하고 그 메모리에 데이터를 저장할 수 있다. 프로세서(32)는 노드의 상태를 반영하기 위해 또는 노드(예를 들어, 도 26 및 도 27), 그리고 특히 UE와 통신하는 하위 네트워크들, 애플리케이션들, 또는 다른 서비스들을 구성하기 위해, 디스플레이 또는 표시자들(42) 상에서의 조명 패턴들, 이미지들, 또는 색상들을 제어하도록 구성될 수 있다. 프로세서(32)는 전원(48)으로부터 전력을 받을 수 있고, 노드(30) 내의 다른 구성요소들에게 전력을 분배 및/또는 제어하도록 구성될 수 있다. 전원(48)은 노드(30)에 전력을 공급하기 위한 임의의 적합한 디바이스일 수 있다. 예를 들어, 전원(48)은 하나 이상의 건전지 배터리(예를 들어, 니켈-카드뮴(NiCd), 니켈-아연(NiZn), 니켈 금속 수소화물(NiMH), 리튬-이온(Li-ion) 등), 태양광 전지, 연료 전지 등을 포함할 수 있다.

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

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

도 28d는, 도 14, 도 22, 도 28a 또는 도 28b에 도시된 것과 같은 M2M 네트워크에서 M2M 서버, 게이트웨이, 디바이스 또는 다른 노드로서 동작할 수 있는, 도 13, 도 15 내지 도 21 및 도 25에 도시된 노드들, 디바이스들과 같은 네트워크의 하나 이상의 노드를 구현하는데 또한 이용될 수 있는 예시적인 컴퓨팅 시스템(90)의 블록도이다.

컴퓨팅 시스템(90)은 컴퓨터 또는 서버를 포함할 수 있으며, 소프트웨어의 형태일 수 있는 컴퓨터 판독가능한 명령어들에 의하거나 그 소프트웨어가 저장되거나 액세스되는 어디든지 또는 어떠한 수단에 의해서도 주로 제어될 수 있다. 이러한 컴퓨터 판독가능한 명령어들은 컴퓨팅 시스템(90)으로 하여금 작업을 수행하게 하기 위해, 중앙 처리 유닛(CPU)(91) 내에서 실행될 수 있다. 많은 알려진 워크스테이션들, 서버들, 및 개인용 컴퓨터들에서, 중앙 처리 유닛(91)은 마이크로프로세서라고 지칭되는 단일-칩 CPU에 의해 구현된다. 다른 기계들에서, 중앙 처리 유닛(91)은 복수의 프로세서들을 포함할 수 있다. 코프로세서(81)는, 추가적 기능들을 수행하거나 CPU(91)를 보조하는, 주 CPU(91)와는 별개인, 임의의 프로세서이다. CPU(91) 및/또는 코프로세서(81)는 보안 보호를 위해 개시된 시스템들 및 방법들에 관련된 데이터를 수신, 생성 및 처리할 수 있다.

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

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

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

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

또한, 컴퓨팅 시스템(90)은 도 28a 및 도 28b의 네트워크(12)와 같은 외부 통신 네트워크에 컴퓨팅 시스템(90)을 연결하여, 컴퓨팅 시스템(90)이 네트워크의 다른 노드들과 통신할 수 있게 하는데 이용될 수 있는, 예를 들어 네트워크 어댑터(97)와 같은 통신 회로를 포함할 수 있다. 통신 회로는 단독으로 또는 CPU(91)와 조합하여 본 명세서(예를 들어, 도 15 내지 도 21 및 도 25) 및 청구항들에서 설명되는 전송 및 수신 단계들을 수행하는데 이용될 수 있다.

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

다음은 이상의 설명에서 나올 수 있는 서비스 기술들에 관련된 약어들의 리스트이다. 달리 명시되지 않는 한, 본 명세서에서 사용된 약어들은 아래 나열된 대응 용어를 지칭한다.

AE 애플리케이션 엔티티

API 애플리케이션 프로그램 인터페이스들

ASN 애플리케이션 특정 노드

CapEX 자본 비용

CPC CSF 풀 제어기

CPM CSF 풀 관리자

CSE 공통 서비스 엔티티

CSF 공통 서비스 기능

CSP 후보 선택 프로세스

GW 게이트웨이

IN 인프라스트럭처 노드

IoT 사물 인터넷

IT 정보 기술

M2M 기계간

MEC 모바일 에지 컴퓨팅

MN 중간 노드

NF 네트워크 기능

NFV 네트워크 기능 가상화

OpEX 운영 비용

OS 운영 체제

RAP 역할 할당 프로세스

REST 표현 상태 전달

RLP 역할 연결 프로세스

RMP 역할 이전 프로세스

ROA 리소스 지향 아키텍처

SOA 서비스 지향 아키텍처

URI 범용 리소스 식별자

VM 가상 기계

VPES VNF 풀 인에이블러 서비스

본 개시내용의 주제의 바람직한 실시예들을 설명함에 있어서, 도면들에 예시된 바와 같이, 명확함을 위해 특정한 용어들이 이용되었다. 그러나, 청구되는 주제는 그렇게 선택된 특정한 용어들로 제한되는 것으로 의도되는 것이 아니며, 각각의 특정한 요소가 유사한 목적을 달성하기 위해 유사한 방식으로 동작하는 모든 기술적 등가물들을 포함한다는 점이 이해되어야 한다.

Claims

장치로서,
프로세서, 메모리 및 통신 회로를 포함하며,
상기 장치는 상기 통신 회로를 통해 M2M(machine-to-machine) 네트워크에 연결되고, 상기 장치는 상기 장치의 상기 메모리에 저장된 컴퓨터 실행가능한 명령어들을 더 포함하고, 상기 컴퓨터 실행가능한 명령어들은, 상기 장치의 상기 프로세서에 의해 실행될 때, 상기 장치로 하여금,
복수의 공통 서비스 엔티티들에게 요청을 전송하는 것 - 상기 요청은 공통 서비스 기능(CSF) 풀 제어기(CPC)에 대한 요구를 나타냄 -,
상기 요청에 응답하여, 상기 복수의 공통 서비스 엔티티들로부터 복수의 응답들을 수신하는 것 - 각각의 응답은 각각의 공통 서비스 엔티티(CSE)가 상기 CPC일 수 있는지 여부에 관련된 정보를 포함하고, 상기 CPC는 복수의 가상 네트워크 기능(VNF) 풀을 통제하고, 각각의 VNF 풀은 각자의 VNF 풀 내의 다른 공통 서비스 인스턴스들과 동일한 네트워크 기능을 제공하는 복수의 공통 서비스 인스턴스를 포함하고, 각각의 VNF 풀은 각자의 CSF 풀 관리자(CPM)에 의해 관리됨 -, 및
각각의 응답으로부터의 상기 정보를 평가하여 상기 복수의 공통 서비스 엔티티들로부터 적어도 하나의 CPC를 선택하는 것
을 포함하는 동작들을 수행하게 하는 장치.
제1항에 있어서,
상기 요청은 각각의 CSE의 현재 용량 및 각각의 CSE가 상기 CPC가 되려고 하는지 여부를 질의하는 장치.
제1항 또는 제2항에 있어서,
상기 장치는 상기 장치로 하여금 추가 동작들을 수행하게 하는 명령어들을 더 포함하며,
상기 추가 동작들은 상기 적어도 하나의 CPC에 대한 역할 프로파일을 생성하는 것을 포함하고, 상기 역할 프로파일은 상기 CPC의 가상 기계에 대한 최소 성능 요구사항, 상기 CPC의 상기 가상 기계에 대한 선호 성능 시간, 역할 이전 전략 및 역할 소프트웨어 업데이트 스케줄 중 적어도 하나를 포함하는 장치.
제3항에 있어서,
상기 장치는 복수의 CSF 풀 제어기들을 선택하고, 상기 역할 프로파일은 상기 CSF 풀 제어기들 각각과 연관된 온 듀티(on-duty) 시간을 더 포함하는 장치.
제3항에 있어서,
상기 장치는 상기 장치로 하여금 추가 동작들을 수행하게 하는 명령어들을 더 포함하며,
상기 추가 동작들은 상기 복수의 공통 서비스 엔티티들 중 적어도 하나의 CSE에게 상기 역할 프로파일을 전송하는 것을 포함하는 장치.
제5항에 있어서,
상기 장치는 상기 장치로 하여금 추가 동작들을 수행하게 하는 명령어들을 더 포함하며,
상기 추가 동작들은, 상기 역할 프로파일에 응답하여, 상기 적어도 하나의 CSE로부터 확인응답을 수신하는 것을 포함하고, 상기 확인응답은 상기 적어도 하나의 CSE가 상기 역할 프로파일에 표시된 대로 상기 적어도 하나의 CSE의 가상 기계 리소스들을 예비(reserve)하기 시작할 것임을 나타내는 장치.
제6항에 있어서,
상기 장치는 상기 장치로 하여금 추가 동작들을 수행하게 하는 명령어들을 더 포함하며,
상기 추가 동작들은 상기 적어도 하나의 CSE에 소프트웨어 패키지를 배포하는 것을 포함하고, 상기 패키지는 상기 적어도 하나의 CSE가 그 자신을 상기 CPC가 되도록 구성할 수 있게 하는 장치.
제6항에 있어서,
상기 장치는 상기 장치로 하여금 추가 동작들을 수행하게 하는 명령어들을 더 포함하며,
상기 추가 동작들은 상기 적어도 하나의 CSE에게 표시를 전송하는 것을 포함하고, 상기 표시는 상기 적어도 하나의 CSE가 그 자신을 상기 CPC가 되도록 구성할 수 있게 하는 장치.
제7항에 있어서,
상기 역할 프로파일은 상기 공통 서비스 엔티티들 중 하나를 백업 CSE로서 식별하며, 상기 적어도 하나의 CPC는 상기 CPC의 역할을 상기 백업 CSE에게 이전할 수 있는 장치.
제7항에 있어서,
상기 장치는 상기 장치로 하여금 추가 동작들을 수행하게 하는 명령어들을 더 포함하며,
상기 추가 동작들은,
상기 적어도 하나의 CPC로부터 상기 CSE가 더 이상 상기 CPC일 수 없다는 것을 나타내는 메시지를 수신하는 것, 및
상기 메시지에 응답하여, 복수의 공통 서비스 엔티티들에게 요청을 전송하는 것, 상기 요청에 응답하여, 상기 복수의 공통 서비스 엔티티들로부터 복수의 응답들을 수신하는 것, 및 각각의 응답으로부터의 상기 정보를 평가하여 상기 복수의 공통 서비스 엔티티들로부터 적어도 하나의 CPC를 선택하는 것을 포함하는 동작들을 반복하는 것을 포함하는 장치.
장치로서,
프로세서, 메모리 및 통신 회로를 포함하며,
상기 장치는 상기 통신 회로를 통해 M2M 네트워크에 연결되고, 상기 장치는 상기 장치의 상기 메모리에 저장된 컴퓨터 실행가능한 명령어들을 더 포함하고, 상기 컴퓨터 실행가능한 명령어들은, 상기 장치의 상기 프로세서에 의해 실행될 때, 상기 장치로 하여금,
복수의 공통 서비스 엔티티들에게 요청을 전송하는 것 - 상기 요청은 공통 서비스 기능(CSF) 풀 관리자(CPM)에 대한 요구를 나타냄 -,
상기 요청에 응답하여, 상기 복수의 공통 서비스 엔티티들로부터 복수의 응답들을 수신하는 것 - 각각의 응답은 각각의 공통 서비스 엔티티(CSE)가 상기 CPM일 수 있는지 여부에 관련된 정보를 포함하고, 상기 CPM은 각자의 가상 네트워크 기능(VNF) 풀을 관리하고, 각각의 VNF 풀은 각자의 VNF 풀 내의 다른 공통 서비스 인스턴스들과 동일한 네트워크 기능을 제공하는 복수의 공통 서비스 인스턴스를 포함함 -, 및
각각의 응답으로부터의 상기 정보를 평가하여 상기 복수의 공통 서비스 엔티티들로부터 적어도 하나의 CPM을 선택하는 것
을 포함하는 동작들을 수행하게 하는 장치.
제11항에 있어서,
상기 요청은 각각의 CSE의 현재 용량 및 각각의 CSE가 상기 CPM이 되려고 하는지 여부를 질의하는 장치.
제11항 또는 제12항에 있어서,
상기 장치는 상기 장치로 하여금 추가 동작들을 수행하게 하는 명령어들을 더 포함하며,
상기 추가 동작들은 상기 적어도 하나의 CPM에 대한 역할 프로파일을 생성하는 것을 포함하고, 상기 역할 프로파일은 상기 CPM의 가상 기계에 대한 최소 성능 요구사항, 상기 CPM의 상기 가상 기계에 대한 선호 성능 시간, 역할 이전 전략 및 역할 소프트웨어 업데이트 스케줄 중 적어도 하나를 포함하는 장치.
제13항에 있어서,
상기 장치는 복수의 CSF 풀 관리자들을 선택하고, 상기 역할 프로파일은 상기 CSF 풀 관리자들 각각과 연관된 온 듀티 시간을 더 포함하는 장치.
제13항에 있어서,
상기 장치는 상기 장치로 하여금 추가 동작들을 수행하게 하는 명령어들을 더 포함하며,
상기 추가 동작들은 상기 복수의 공통 서비스 엔티티들 중 적어도 하나의 CSE에게 상기 역할 프로파일을 전송하는 것을 포함하는 장치.
제15항에 있어서,
상기 장치는 상기 장치로 하여금 추가 동작들을 수행하게 하는 명령어들을 더 포함하며,
상기 추가 동작들은, 상기 역할 프로파일에 응답하여, 상기 적어도 하나의 CSE로부터 확인응답을 수신하는 것을 포함하고, 상기 확인응답은 상기 적어도 하나의 CSE가 상기 역할 프로파일에 표시된 대로 상기 적어도 하나의 CSE의 가상 기계 리소스들을 예비하기 시작할 것임을 나타내는 장치.
제16항에 있어서,
상기 장치는 상기 장치로 하여금 추가 동작들을 수행하게 하는 명령어들을 더 포함하며,
상기 추가 동작들은 상기 적어도 하나의 CSE에 소프트웨어 패키지를 배포하는 것을 포함하고, 상기 패키지는 상기 적어도 하나의 CSE가 그 자신을 상기 CPM이 되도록 구성할 수 있게 하는 장치.
제16항에 있어서,
상기 장치는 상기 장치로 하여금 추가 동작들을 수행하게 하는 명령어들을 더 포함하며,
상기 추가 동작들은 상기 적어도 하나의 CSE에게 표시를 전송하는 것을 포함하고, 상기 표시는 상기 적어도 하나의 CSE가 그 자신을 상기 CPM이 되도록 구성할 수 있게 하는 장치.
제17항에 있어서,
상기 장치는 상기 장치로 하여금 추가 동작들을 수행하게 하는 명령어들을 더 포함하며,
상기 추가 동작들은 CSF 풀 제어기(CPC)인 다른 CSE의 아이덴티티를 상기 적어도 하나의 CSE에게 통보하며, 상기 적어도 하나의 CSE는 상기 CPC인 상기 CSE와 접촉할 수 있는 것을 포함하고, 상기 CPC는 복수의 VNF 풀을 통제하고, 각각의 VNF 풀은 각자의 CPM에 의해 관리되는 장치.
제7항에 있어서,
상기 장치는 상기 장치로 하여금 추가 동작들을 수행하게 하는 명령어들을 더 포함하며,
상기 추가 동작들은 CPM인 다른 CSE의 아이덴티티를 상기 적어도 하나의 CSE에게 통보하며, 상기 적어도 하나의 CSE는 상기 CPM인 상기 CSE와 접촉할 수 있는 것을 포함하는 장치.
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제