KR20190092441A - M2m iot 서비스 계층에서 유연한 과금을 가능하게 하는 방법들 - Google Patents

Abstract

본 출원은 적어도 네트워크 상의 장치에 관한 것이다. 장치는 이벤트의 온라인 과금을 위한 명령어들이 저장된 비-일시적 메모리를 포함한다. 장치는 또한 비-일시적 메모리에 동작가능하게 결합된 프로세서를 포함한다. 프로세서는 M2M 게이트웨이로부터 서비스 계층 온라인 과금을 위한 요금율 요청 메시지를 수신하는 명령어들을 실행하도록 구성된다. 프로세서는 또한 이벤트에 대해 과금하기 위한 요금율 체계를 결정하는 명령어들을 실행하도록 구성된다. 프로세서는 요금율 요청 메시지 및 결정된 요금율 체계에 기초하여 서비스 유닛들의 양을 계산하는 명령어들을 실행하도록 추가로 구성된다. 프로세서는 M2M 게이트웨이에, 서비스 유닛들의 계산된 양에 기초하여 요금율 응답을 송신하는 명령어들을 실행하도록 추가로 더 구성된다.

Description

M2M IOT 서비스 계층에서 유연한 과금을 가능하게 하는 방법들

본 출원은 2016년 11월 14일자로 출원된 "M2M IoT 서비스 계층에서 유연한 과금을 가능하게 하는 방법들(Methods of Enabling Flexible Charging in M2M IoT Service Layer)"이라는 명칭의 미국 가특허 출원 제62/421,715호의 우선권의 혜택을 주장하며, 그것의 내용은 전체가 참조에 의해 통합된다.

과금 데이터 레코드들(CDR)은 전송 네트워크 또는 서비스 계층에서 생성되고, "청구서 작성 시스템(billing system)"에 보내지며, 종종 청구서를 생성하기 위해 사용된다. 그러나, CDR들은 청구서 작성 및 과금보다 더 많은 것을 위해 사용된다.

CDR은 네트워크 또는 서비스 계층에서 발생한 소정의 이벤트를 캡처하는 레코드이다. 매우 자주, 이벤트는 고객의 청구서에 영향을 줄 수 있는 이벤트이다. 예를 들어, 이벤트는 디바이스가 10 메가바이트를 다운로드한 것일 수 있다. 그러나, 이벤트는 켜진 것, 다른 접속 지점으로 이동된 것 등일 수 있다. 이러한 이벤트들은 고객의 청구서에 거의 영향을 미치지 않지만, CDR들은 여전히 생성된다.

일부 이벤트들은 수 개의 네트워크 노드 또는 기능을 수반할 수 있으며, 각각의 기능은 각각의 이벤트에 대해 별도의 CDR을 생성할 수 있다. 이것은 고객이 하나의 이벤트에 대해 여러 회 과금된다는 것을 의미하지는 않으며, 단순히 복수의 노드가 이벤트에 대한 레코드를 생성할 것임을 의미한다.

중복 CDR들 및 청구서를 작성할 수 없는 이벤트들을 기록하는 CDR들은 유용하다고 고려된다. 구체적으로, 그들은 네트워크 운영자들 및 서비스 제공자들이 자신의 시스템을 디버그하고 고객의 활동을 분석하는 데 사용된다. 또한, 그들은 네트워크 운영자들 및 서비스 제공자들이 그들의 고객이 다른 제공자들의 서비스를 사용하거나 로밍하고 있을 때 다른 네트워크 운영자들 및 서비스 제공자들과의 계정을 청산하는 데에도 사용된다.

본 개요는 아래에서 상세한 설명에 더 설명되는 단순화된 형태의 개념들의 선택을 소개하기 위해 제공된다. 본 개요는 청구된 주제의 핵심적인 특징들 또는 필수적인 특징들을 식별하도록 의도되지 않으며, 청구된 주제의 범위를 제한하는 데 사용되도록 의도되지도 않는다. 또한, 청구된 주제는 본 개시내용의 임의의 부분에서 언급된 임의의 또는 모든 단점을 해결하는 제한들에 한정되지 않는다.

본 출원의 양태는 네트워크 상의 장치에 관한 것이다. 장치는 이벤트의 온라인 과금을 위한 명령어들이 저장된 비-일시적 메모리를 포함한다. 장치는 또한 비-일시적 메모리에 동작가능하게 결합된 프로세서를 포함한다. 프로세서는 M2M 게이트웨이로부터 서비스 계층 온라인 과금을 위한 요금율 요청 메시지(rating request message)를 수신하는 명령어들을 실행하도록 구성된다. 프로세서는 또한 이벤트에 대해 과금할 요금율 체계(rating scheme)를 결정하는 명령어들을 실행하도록 구성된다. 프로세서는 요금율 요청 메시지 및 결정된 요금율 체계에 기초하여 서비스 유닛들의 양을 계산하는 명령어들을 실행하도록 추가로 구성된다. 또한, 프로세서는 M2M 게이트웨이에, 계산된 서비스 유닛들의 양에 기초하여 요금율 응답을 송신하는 명령어들을 실행하도록 구성된다.

본 출원의 다른 양태는 네트워크 상에서 동작하는 장치에 관한 것이다. 장치는 요금율 정보를 구성하기 위한 명령어들이 저장된 비-일시적 메모리를 포함한다. 장치는 또한 비-일시적 메모리에 동작가능하게 결합된 프로세서를 포함한다. 프로세서는 발원자(originator)로부터 요금율 정보를 포함하는 요금율 구성 요청 메시지(configure rating request message)를 수신하는 명령어들을 실행하도록 구성된다. 프로세서는 또한 발원자로부터 수신된 요금율 정보를 M2M 서버에 저장하는 명령어들을 실행하도록 구성된다. 프로세서는 M2M 서버 내의 서비스 도메인 과금 트리거 기능부에서 요금율 정보를 구성하는 명령어들을 실행하도록 추가로 구성된다. 또한, 프로세서는 M2M 서버로부터, 구성된 요금율 정보를 포함하는 응답을 발원자에게 송신하는 명령어들을 실행하도록 추가로 구성된다.

첨부 도면들과 함께 예로서 주어진 이하의 설명으로부터 보다 더 구체적인 이해가 이루어질 수 있다.
도 1은 논리적 오프라인 과금 아키텍처를 도시하는 도면이다.
도 2는 논리적 온라인 과금 아키텍처를 도시하는 도면이다.
도 3은 비-로밍 시나리오에 대한 오프라인 IMS 과금 아키텍처를 도시하는 도면이다.
도 4는 서비스 계층을 지원하는 예시적인 프로토콜 스택을 도시하는 도면이다.
도 5는 공통 서비스 엔티티(CSE) 및 공통 서비스 기능부(CSF)를 도시하는 도면이다.
도 6은 oneM2M 서비스 계층 기능 아키텍처(ROA)를 도시하는 도면이다.
도 7은 oneM2M ROA에 대한 정보 레코드를 위한 리소스들을 도시하는 도면이다.
도 8은 과금을 위한 리소스들의 사용 예를 도시하는 도면이다.
도 9는 애플리케이션들을 위한 이벤트 기반 통계 수집을 도시하는 도면이다.
도 10은 오픈 메시지 버스(OMB) 아키텍처를 도시하는 도면이다.
도 11은 데이터 분석 서비스 및 데이터 프로비저닝 서비스에 대한 유연한 과금을 위한 사용 사례를 도시하는 도면이다.
도 12는 oneM2M 서비스 계층 오프라인 과금의 기능적 아키텍처를 도시하는 도면이다.
도 13은 oneM2M 서비스 계층 온라인 과금의 기능적 아키텍처를 도시하는 도면이다.
도 14는 "가입 생성" 이벤트를 과금하기 위한 오프라인 과금 절차의 예를 도시하는 도면이다.
도 15는 요금율 정보를 구성하는 절차를 도시하는 도면이다.
도 16은 요금율 기능부를 사용하는 예약 기반 서비스 계층 온라인 과금의 절차들을 도시하는 도면이다.
도 17은 OMB 내의 서비스 계층 과금 서비스의 아키텍처를 다양한 배치 시나리오들과 함께 도시하는 도면이다.
도 18은 제1 시나리오에 대한 오프라인 과금 절차를 도시하는 도면이다.
도 19는 제1 시나리오에 대한 온라인 과금 절차를 도시하는 도면이다.
도 20은 유연한 서비스 계층 과금을 갖는 SGi-LAN의 예시적인 아키텍처를 도시하는 도면이다.
도 21은 서비스 계층 과금 기능성의 구성의 예시적인 그래픽 사용자 인터페이스(GUI)를 도시하는 도면이다.
도 22a는 통신 네트워크를 포함하는 M2M/IoT/WoT 통신 시스템의 도면이다.
도 22b는 M2M 애플리케이션, M2M 게이트웨이 디바이스들, 및 M2M 단말 디바이스들 및 통신 네트워크에 대한 서비스들을 제공하는 필드 도메인 내의 예시된 M2M 서비스 계층의 도면이다.
도 22c는 본 명세서에 설명된 네트워크 노드들, 디바이스들 또는 장치들 중 임의의 것을 구현하기 위해 사용될 수 있는 예시적인 디바이스의 도면이다.
도 22d는 본 명세서에 설명된 네트워크 노드들, 디바이스들 또는 장치들 중 임의의 것을 구현하기 위해 사용될 수 있는 컴퓨터 시스템 또는 서버의 블록도이다.

예시적인 실시예들의 상세한 설명은 본 명세서의 다양한 도면들, 실시예들 및 양태들을 참조하여 논의될 것이다. 이 설명은 가능한 구현의 상세한 예들을 제공하지만, 상세한 설명은 예시적인 것으로 의도되고, 따라서 본 출원의 범위를 제한하지 않는다는 것을 이해해야 한다.

본 명세서에서 "일 실시예", "실시예", "하나 이상의 실시예", "양태" 등에 대한 언급은 그 실시예와 관련하여 설명된 특정한 특징, 구조 또는 특성이 본 개시내용의 적어도 일 실시예에 포함된다는 것을 의미한다. 더욱이, 본 명세서의 다양한 장소들에서의 "실시예"라는 용어는 반드시 동일한 실시예를 지칭하는 것은 아니다. 즉, 일부 실시예들에 의해서는 나타날 수 있지만 다른 실시예들에 의해서는 나타나지 않을 수 있는 다양한 특징들이 설명된다.

일반적으로, 본 출원은 M2M IoT 서비스 계층들에서의 유연한 과금을 가능하게 하기 위한 방법들 및 시스템들에 관한 것이다. 실시예에서, 흐름-기반 모델은 네트워크에 연관된 디바이스들에 과금하기 위해, 전통적인 전송 네트워크에 의한 과금, 즉 데이터의 양 또는 단위 시간 당 데이터의 양에 적용된다. 현재, 네트워크 운영자들은 예를 들어 콘텐츠 제공자, 피크 시간 대 비-피크 시간, 및 액세스 네트워크의 유형에 기초하는 요금들과 같은 소정의 컨텍스트 정보를 사용하여 정교한 과금 메커니즘을 사용한다. 그러나, 이러한 컨텍스트 정보는 주로 디바이스 레벨 또는 종래의 컨텍스트 정보이다. 사용된 애플리케이션 레벨 정보는 많지 않다. 전송 네트워크 엔티티가 애플리케이션 정보 또는 서비스 컨텍스트에 액세스하고 애플리케이션 레벨 정보를 해석하는 것은 쉽지 않습니다. 즉, 전송 네트워크 내의 네트워크 엔티티는 서비스 흐름의 내용, 예를 들어 검색(retrieve)되고 있는 데이터가 의료 정보에 관한 것인지 날씨 보고에 관한 것인지를 구별하지 못할 수도 있다. 한편, 서비스 계층 내의 엔티티는 애플리케이션 정보 및 서비스 컨텍스트를 해석할 수 있으므로, 서비스 계층에서의 과금이 더 유연해질 수 있다. 동일한 서비스에 대해서도, 상이한 과금 방법들, 과금 레이트들 및 과금 측정 메트릭들을 사용하여, 상이한 엔티티들에 의해 상이한 과금 체계들이 적용될 수 있다.

다른 실시예에서, 방법들 및 시스템들은 서비스 계층에서의 유연한 과금 서비스에 관한 것이다. 상이한 엔티티들(예를 들어, 서비스 제공자)은 동일한 서비스를 이용한 것에 대하여, 상이한 과금 방법들(즉, 오프라인 또는 온라인), 과금 모델들(예를 들어, 가입 기반, 트랜잭션 기반), 과금 레이트들, 및 과금 측정들(예를 들어, 시간, 용량)을 애플리케이션들에 적용할 수 있다. 특정 유형들의 애플리케이션 및 서비스 컨텍스트가 정의되어 이러한 능력을 가능하게 하는 데 사용된다. 오프라인 및 온라인 과금 둘 다가 지원된다.

약어 및 정의

이하의 약어들은 본 출원에서 자주 사용되는 용어들 및 문구들에 사용된다.

AMBF 계정 및 잔액 관리 기능부(Account and Balance Management Function)

ADN 애플리케이션 전용 노드(Application Dedicated Node)

AF 애플리케이션 기능부(Application Function)

API 애플리케이션 프로그래밍가능 인터페이스(Application Programmable Interface)

ASN 애플리케이션 서비스 노드(Application Service Node)

BD 청구서 작성 도메인(Billing Domain)

CDR 과금 데이터 레코드(Charging Data Record)

CDF 과금 데이터 기능부(Charging Data Function)

CGF 과금 게이트웨이 기능부(Charging Gateway Function)

CTF 과금 트리거 기능부(Charging Trigger Function)

CSE 공통 서비스 엔티티(Common Service Entity)

CSF 공통 서비스 기능부(Common Service Function)

EPC 진화된 패킷 코어(Evolved Packet Core)

GDI 일반 데이터베이스 인터페이스(Generic Database Interface)

IE 정보 요소(Information Element)

IMS IP 멀티미디어 서브시스템(IP Multimedia Subsystem)

MN 중간 노드(Middle Node)

NSSE 네트워크 서비스 노출, 서비스 실행 및 트리거링(Network Service Exposure, Service Execution and Triggering)

OCS 온라인 과금 시스템(Online Charging System)

OFCS 오프라인 과금 시스템(Offline Charging System)

OMB 오픈 메시지 버스(Open Message Bus)

PCC 정책 및 과금 제어(Policy and Charging Control)

PCEF 정책 및 과금 시행 기능부(Policy and Charging Enforcement Function)

PCRF 정책 및 과금 규칙 기능부(Policy and Charging Rules Function)

PDN 패킷 데이터 네트워크들(Packet Data Networks)

RF 요금율 기능부(Rating Function)

ROA 리소스 지향 아키텍처(Resource Oriented Architecture)

SC 서비스 능력(Service Capability)

SCA 서비스 과금 및 회계(Service Charging and Accounting)

SCEF 서비스 능력 노출 기능부(Service Capability Exposure Function)

SD-CDR 서비스 도메인 과금 데이터 레코드(Service Domain Charging Data Record)

SD-CTF 서비스 도메인 과금 트리거 기능부(Service Domain Charging Trigger Function)

SD-CS 서비스 도메인 과금 시스템(Service Domain Charging System)

SD-OFCS 서비스 도메인 오프라인 과금 시스템(Service Domain Offline Charging System)

SD-OCS 서비스 도메인 온라인 과금 시스템(Service Domain Online Charging System)

SD-RF 서비스 도메인 요금율 기능부(Service Domain Rating Function)

SD-ABMF 서비스 도메인 회계 및 잔액 관리 기능부(Service Domain Account and Balance Management Function)

이하의 정의들은 본 출원에서 사용되는 용어들에 대해 제공된다.

오프라인 과금 기능부

도 1은 논리적 오프라인 과금 아키텍처를 도시한다. 오프라인 과금은 네트워크 리소스 사용에 대한 과금 정보가 그 리소스 사용과 동시에 수집되는 프로세스이다. 과금 정보는 논리적 과금 기능들의 체인을 통해 전달된다. 이 프로세스의 끝에서, CDR 파일들은 네트워크에 의해 생성된 다음, 가입자 청구서 작성 및/또는 운영자 간 회계(또는 운영자의 재량에 따른 추가 기능들, 예를 들어 통계)를 목적으로, 네트워크 운영자의 청구서 작성 도메인(BD)에 전달된다. BD는 전형적으로 운영자의 청구서 작성 시스템 또는 청구서 작성 중개 디바이스와 같은 사후 처리 시스템들을 포함한다. 오프라인 과금은 렌더링되는 서비스에 과금 정보가 실시간으로 영향을 미치지 않는 메커니즘이다.

온라인 과금 기능부

도 2는 논리적 온라인 과금 아키텍처를 도시한다. 온라인 과금은 오프라인 과금에서와 동일한 방식으로, 네트워크 리소스 사용에 대한 과금 정보가 그 리소스 사용과 동시에 수집되는 프로세스이다. 그러나, 네트워크 리소스 사용에 대한 인가는 실제 리소스 사용이 발생하기 전에 네트워크에 의해 획득되어야 한다. 이 인가는 네트워크로부터의 요청 시에 온라인 과금 시스템(OCS)에 의해 승인된다.

네트워크 리소스 사용 요청을 수신하면, 네트워크는 관련 과금 정보를 모으고 실시간으로 OCS에 대한 과금 이벤트를 생성한다. 다음으로, OCS는 적절한 리소스 사용 인가를 리턴한다. 리소스 사용 인가는 그것의 범위(예를 들어, 데이터의 양 또는 지속시간)에 있어서 제한될 수 있다. 그러므로, 사용자의 네트워크 리소스 사용이 지속되는 한, 인가는 수시로 갱신되어야 할 수 있다.

온라인 과금은 렌더링되는 서비스에 과금 정보가 실시간으로 영향을 미칠 수 있는 메커니즘이다. 그러므로, 과금 메커니즘과 네트워크 리소스 사용의 제어의 직접 상호작용이 요구된다.

일반적으로, 흐름-기반 과금 모델이 3GPP에서 사용되는데, 즉 네트워크 리소스 사용은 서비스 흐름마다 식별되며, 과금 세분도(charging granularity)는 데이터 크기, 데이터 속도 등에 기초할 수 있다. 이는 애플리케이션 정보 또는 서비스 컨텍스트가 주로 전송 네트워크인 3GPP 네트워크에서 투명하기 때문이다. 네트워크 엔티티는 데이터 흐름의 내용, 예를 들어 데이터 비트가 비디오 플로우를 위한 것인지 또는 텍스트 파일을 위한 것인지, 또는 데이터가 의료 보고를 위한 것인지 날씨 보고를 위한 것인지를 구별할 수 없다.

최근, 3GPP는 소정의 애플리케이션 레벨 정보를 수반하도록 스폰서 데이터 접속을 정의했다. 스폰서 데이터 접속으로 과금하는 하나의 가능한 시나리오는 애플리케이션 서비스 제공자가 사용자들에게 과금하는 것이다. 애플리케이션 서비스 제공자는 사용자들에 의해 사용되는 3GPP 네트워크 리소스의 사용에 대해 지불할 것이다.

IMS 과금 아키텍처

도 3은 비-로밍 시나리오를 위한 오프라인 IMS 과금 아키텍처를 도시한다. IMS(IP Multimedia Subsystem) 네트워크는 3GPP에 의해 정의된 아키텍처를 사용하고, 3GPP에 의해 정의된 과금 기반구조와 기준점들도 사용한다. 일반적으로, IMS 과금은 하나의 유형의 서비스/애플리케이션, 즉 SCS/AS로서의 IMS 네트워크로 과금한다. 세션 정보 및 전송 과금 ID와 같은 소정의 컨텍스트 정보가 존재한다. 정보는 3GPP에 의해 정의된 현재의 다이어미터 메시지들에 기초한다. 도 3은 PDSN이 패킷 데이터 서빙 노드이고 CSCF가 호출 세션 제어 기능부인, 로밍 없는 IMS 네트워크의 오프라인 과금 아키텍처를 도시한다.

서비스 계층

프로토콜 스택의 관점에서, 서비스 계층들은 전형적으로 애플리케이션 프로토콜 계층 위에 놓이고, 클라이언트 애플리케이션들에 부가 가치 서비스들을 제공한다. 그러므로, 서비스 계층들은 종종 '미들웨어' 서비스들로 범주화된다. 예를 들어, 도 4는 IP 네트워크 스택(404)과 애플리케이션들(406) 사이의 예시적인 서비스 계층(402)을 도시한다.

M2M/IoT 서비스 계층(402)은 구체적으로 M2M/IoT 유형의 디바이스들 및 애플리케이션들을 위한 부가 가치 서비스들을 제공하는 것을 목표로 하는 한 유형의 서비스 계층의 예이다. 최근, 몇 개의 산업 표준 기관[예를 들어, oneM2M(eM2M-TS-0001 oneM2M 기능 아키텍처-V2.5.0)]은 M2M/IoT 서비스 계층들을 개발하여, M2M/IoT 유형의 디바이스들 및 애플리케이션들을 인터넷/웹, 셀룰러, 기업 및 홈 네트워크와 같은 배치에 통합하는 것에 연관된 난제들을 해결해왔다.

M2M 서비스 계층(402)은 서비스 계층에 의해 지원되는 M2M 지향 능력들의 모음에 대한 애플리케이션들 및 디바이스들의 액세스를 제공할 수 있다. 몇몇 예들은 보안, 과금, 데이터 관리, 디바이스 관리, 발견, 프로비저닝, 및 접속 관리를 포함한다. 이러한 능력들은 M2M 서비스 계층(402)에 의해 정의되는 메시지 형식들, 리소스 구조들, 및 리소스 표현들을 활용하는 API을 통해 애플리케이션에서 이용가능하게 된다.

oneM2M 서비스 계층 아키텍처

oneM2M은 다양한 하드웨어 및 소프트웨어에 쉽게 임베드될 수 있는 공통 M2M 서비스 계층의 필요성을 해결하는 기술 사양들을 개발하는 새로운 표준이고, 현장의 여러 다양한 디바이스들을 전세계의 M2M 애플리케이션 서버들에 접속하는 것에 의존한다.

oneM2M 공통 서비스 계층은 도 5에 도시된 바와 같이 공통 서비스 기능부들(CSF)(즉, 서비스 능력들)의 세트를 지원한다. 하나 이상의 특정 유형의 CSF들의 세트의 인스턴스화는 공통 서비스 엔티티(Common Services Entity)(CSE)(502)로 지칭되고, 상이한 유형들의 네트워크 노드들(예를 들어, 기반구조 노드, 중간 노드, 애플리케이션-특정 노드)에서 호스팅될 수 있다.

oneM2M은 도 6에 도시된 RoA(Resource Oriented Architecture)에서 서비스 계층을 개발하고 있다. 리소스는 생성(Create), 검색(Retrieve), 업데이트(Update), 및 삭제(Delete)와 같은 RESTful 메서드들을 통해 조작될 수 있는 표현을 갖는 아키텍처 내에서 고유하게 어드레스가능한 요소이다. 이러한 리소스들은 유니버설 리소스 식별자들(Universal Resource Identifiers)(URI)을 사용하여 어드레스가능하게 된다. 리소스는 자식 리소스(들) 및 속성(들)을 포함할 수 있다. 자식 리소스는 부모 리소스와의 포함 관계를 갖는 리소스이다. 부모 리소스 표현은 그것의 자식 리소스(들)에 대한 참조들을 포함한다. 자식 리소스의 수명은 부모의 리소스 수명에 의해 제한된다. 각각의 리소스는 리소스의 정보를 저장하는 "속성들"의 세트를 지원한다.

oneM2M ROA에서의 과금 메커니즘

eM2M-TS-0001에서, 일부 리소스들은 과금 활동 또는 도 7에 일반적으로 도시된 정보 기록을 가능하게 하기 위해 정의된다.

● <eventConfig>: 서비스 계층 동작에 대응하는 이벤트를 정의한다. 과금의 관점에서, 그것은 과금 이벤트를 정의한다.

● <statsConfig>: 상이한 서비스 제공자들 또는 애플리케이션 서비스 제공자들에 의해 구성되는 다양한 유형의 이벤트들을 표현하는 <eventConfig> 리소스들의 목록을 포함한다.

● <statsCollect>: 주어진 과금 이벤트에 대해 정보 수집을 트리거할 정보뿐만 아니라 일부 조건들을 정의한다.

도 8은 과금을 위해 사용되는 이러한 리소스들의 예를 보여준다. 예는 또한 이러한 리소스들 사이의 관계를 드러낸다.

도 9는 기반구조 노드에 기초하는 서비스 계층 이벤트 기반 과금의 예를 보여주며, SCA는 oneM2M에 의해 정의된 '서비스 과금 및 계정(service charging and account' CSF이다.

도 8 및 도 9는 서비스 계층에서 과금을 수행하기 위한 리소스들 및 기본 절차를 정의하지만, 이것은 고급 과금 메커니즘을 수행하기에는 충분하지 않다. 과금 절차들에서 다양한 애플리케이션 정보를 완전히 이용하기 위해서는, 더 많은 정보 요소들이 정의된 고급 메커니즘들이 요구된다.

기존 메시징 기반 미들웨어 아키텍처

IT 서비스들은 다양한 동작 환경들(하드웨어 플랫폼들, 운영 체제들 등)에 배치될 수 있다. 메시지 기반 미들웨어는 통신 서비스들 사이의 "메시지 계층"을 제공하고, 따라서 각각의 서비스가 실행되는 기본 동작 환경을 추상화한다. 즉, "메시지 계층"은 서비스들 사이에 메시지들을 교환하는 중개자 역할을 한다.

미들웨어 계층은 메시지 큐의 개념에 기초할 수 있다. 큐 기반 미들웨어 아키텍처는 다수의 상이한 형태를 취할 수 있고; 모든 서비스에 메시지를 송신하기 위해 사용되는 단일 공유 큐, 각각의 서비스가 그로부터 메시지들을 수신하는 전용 큐, 각각의 서비스가 그에 메시지들을 송신하는 전용 큐 등이 존재할 수 있다.

게시/가입 모델에서, 메시지들은 미들웨어 내의 목적지에 송신(게시)된다. 목적지는 메시지 "주제"에 의존한다. 특정 주제에 관련된 메시지들을 수신하기 원하는 서비스들은 그 주제에 "가입"한다. 메시지 브로커라는 용어는 일반적으로 모든 메시지를 수신하고 모든 메시지를 배포하는 엔티티를 지칭한다. 브로커는 다수의 큐로 구현될 수 있거나, 다수의 주제를 갖는 게시/가입 아키텍처로서 구현될 수 있는 등이다.

고급 메시지 큐잉 프로토콜(Advanced Message Queuing Protocol)(AMQP)은 메시지 버스 프로토콜이다. 메시지 버스는 미들웨어의 한 유형이다. AMQP 익스체인지(Exchange)는 서비스로부터 메시지들을 수락하고 메시지를 하나 이상의 큐에 라우팅한다. 익스체인지는 정적 규칙에 기초하여(즉, 모두가 메시지를 이러한 5개의 서비스에 송신함), 어떤 큐들이 그들을 익스체인지에 바인딩하는지에 기초하여, 메시지 주제에 기초하여, 또는 메시지 헤더 내의 값들에 기초하여 메시지를 라우팅하도록 설계될 수 있다.

메시지 큐잉 텔레메트리 전송(Message Queuing Telemetry Transport)(MQTT)(OASIS MQTT V3.1.1 위원회 사양 01, 2014년 5월 18일)은 다른 메시지 버스 프로토콜이다. MQTT는 페이스북 메신저 모바일 애플리케이션에 가장 흔하게 배치되는 제약된 디바이스들 및 저 대역폭 네트워크들에 맞춤화된 낮은 오버헤드 메시지 큐 및 전송 프로토콜이다.

오픈 메시지 버스( OMB )

OMB는 서비스들 사이의 접속 및 통신을 제공하기 위해 개발된 메시징 시스템 아키텍처이다. 도 10은 OMB 아키텍처를 도시한다.

OMB 백본은 OMB에 접속된 모든 서비스에 의해 활용될 수 있는 일부 기반구조 서비스들을 제공한다. 기반구조 서비스들은 데이터베이스 서비스들, 발견 서비스들, 및 관리 서비스들을 포함한다.

● OMB 데이터베이스 서비스는 모든 다른 서비스들에 의해 정보를 저장하고 질의하기 위해 사용된다. 데이터베이스 서비스들은 일반 데이터베이스 인터페이스(Generic Database Interface)(GDI) 서비스의 최상위에 설계된다. 데이터베이스 서비스(RDBMS 및 DBMS)의 코어는 대부분 OMB를 인식하지 못한다. GDI 서비스는 OMB API의 서비스와 인터페이스하도록 설계된다. GDI 서비스에 정의된 주요 기능들은 데이터베이스 서비스에 대한 등록 또는 등록 취소, 데이터베이스 내의 정보의 생성/업데이트/검색/삭제, 및 데이터베이스에 대한 질의이다.

● OMB 발견 서비스는 OMB에 접속된 서비스들의 동적 발견 및 게시를 위해 사용된다. OMB 디렉토리 서비스는 DNS 서비스 발견(DNS-SD) 인터페이스는 물론, OMB 인터페이스를 지원한다. DNS-SD 인터페이스는 서비스들이 OMB에 액세스하지 않고서 서비스 디렉토리를 브라우징하는 것을 허용한다. 이것은 서비스들이 OMB에 참여하기로 결정하기 전에 OMB에 의해 제공되는 서비스들이 무엇인지를 동적으로 체크하기를 원할 때 특히 유용하다.

● OMB 관리 서비스들은 OMB에 접속하는 클라이언트 서비스들을 관리하고 모니터링하기 위해 사용된다.

서비스가 OMB에 참여하고 나면, 그것은 OMB 클라이언트가 된다. OMB 클라이언트는 서비스 디렉토리에 가입하고, 특정 서비스들 또는 서비스들의 클래스들이 OMB에 접속되거나 그로부터 접속 해제될 때 통지를 수신할 수 있다. 모든 서비스는 OMB에 의해 사용되는 기저 전송 네트워크들(예를 들어, AMQP, UDP, MQTT, XMPP, 웹소켓 등)과 서비스들 사이의 추상화(즉, API)의 계층을 제공하는 OMB 클라이언트들을 통해 OMB에 인터페이스한다.

사용 사례들

서비스/애플리케이션 컨텍스트에 기초하는 유연한 서비스 계층 과금을 보여주는 사용 사례가 도 11에 도시되어 있다. 서비스 계층 플랫폼(1102)은 데이터 저장 서비스 및 데이터 분석 서비스를 제공한다. 애플리케이션들(1104, 1106 및 1108)은 저장소를 제공하는 플랫폼에 데이터를 업로드한다. 이러한 의미에서, 애플리케이션은 데이터 저장 서비스를 사용하는 것에 대해 플랫폼 운영자에 의해 과금된다. 한편, 플랫폼에 저장된 데이터는 다른 애플리케이션들에 의해 검색될 수 있다. 이 시나리오에서, 데이터를 소비하는 애플리케이션은 데이터를 제공하는 애플리케이션에 의해 과금된다. 데이터를 소비하는 애플리케이션이 또한 데이터를 검색할 때 데이터 분석 서비스를 이용하는 경우, 그것은 또한 플랫폼 운영자, 즉 서비스 제공자에 의해 과금될 것이다. 데이터 제공자 및 서비스 제공자는 각각 과금 정책을 구성할 것이다. 추가로, 서비스 계층 플랫폼(1102)은 과금 정보를 수집하고 이 정보를 청구서 작성 시스템에 공급하는 자기 자신의 과금 시스템을 갖는다.

가입 프로파일에 기초하여, 상이한 애플리케이션들은 상이한 과금 모델들(즉, 과금 엔티티, 과금 방법, 레이트 및 측정값)을 적용받을 수 있다:

● 애플리케이션 1[비디오 카메라(1104)]은 데이터 저장 서비스에 가입한다. 그것은 비디오를 서비스 계층 플랫폼(1102)에 업로드한다. 따라서, 애플리케이션 1은 그것이 업로드하는 데이터 용량에 기초하여 데이터를 저장하는 것에 대해 플랫폼 운영자에 의해 과금된다.

● 애플리케이션 2[스마트 워치(1106)]는 고정 월별 가입료로 데이터 저장 서비스에 가입한다. 그것은 주기적으로 의료적 측정값(예를 들어, 심장 박동수)을 플랫폼에 업로드한다.

● 애플리케이션 3[스마트 폰(1108)]은 데이터 유형들 둘 다에 가입한다. 한편, 그것은 의료 데이터와만 결합된 분석 서비스에 가입한다. 그것은 데이터 제공자(즉, 비디오 카메라)에 의해 그것이 플랫폼으로부터 검색한 비디오의 데이터 용량에 기초하여 과금될 것이다. 추가로, 온라인 과금 방법이 사용된다. 의료 정보에 대해, 그것은 의료 데이터가 분석 서비스에 의해 처리되고, 소정의 비정상적인 의학적 상태를 보일 때 통지를 받을 것이다. 통지는 데이터 분석 서비스의 결과이다. 플랫폼 운영자는 발송된 통지마다 애플리케이션 3에 과금한다. 본질적으로, 애플리케이션 3은 의료 데이터 및 분석 능력을 함께 사용하여 과금된다.

더 많은 애플리케이션 정보와 서비스 컨텍스트가 주어지면, 서비스 계층 과금은 매우 유연해질 수 있다.

흐름-기반 과금 모델은 종래의 전송 네트워크(예를 들어, 3GPP)에서 사용되는데, 즉 사용자는 네트워크 리소스를 사용하는 것에 대해 서비스 흐름 별로 과금되고, 이는 전송된 데이터의 양 또는 데이터 속도(즉, 초당 비트 수)에 기초할 수 있다. 현재, 네트워크 운영자는 콘텐츠 제공자에 기초하거나, 피크 시간 대 비-피크 시간에 기초하거나, 액세스 네트워크의 유형에 기초하는 과금과 같이, 소정의 컨텍스트 정보를 사용하여 더 정교한 과금 메커니즘을 적용한다. 그러나, 그 컨텍스트 정보는 주로 디바이스 레벨 또는 종래의 컨텍스트 정보이고, 사용되는 애플리케이션 레벨 정보는 많지 않다. 전송 네트워크 엔티티가 애플리케이션 정보 또는 서비스 컨텍스트에 액세스하고 애플리케이션 레벨 정보를 해석하는 것은 쉽지 않다. 즉, 전송 네트워크 내의 네트워크 엔티티는, 예를 들어 검색되는 데이터가 의료 정보에 관한 것인지 또는 날씨 보고에 관한 것인지와 같이, 서비스 흐름의 콘텐츠를 구별하지 못할 수 있다.

한편, 사용 사례들에 도시되고 위에서 논의된 바와 같이, 서비스 계층에서 더 많은 애플리케이션 및 서비스 컨텍스트가 이용가능하다. 결국, 서비스 계층 네트워크 엔티티는 이 정보에 더 액세스하고 해석할 수 있다. 동일한 서비스에 대해서도, 상이한 애플리케이션들은 상이한 과금 방법들, 과금 레이트들, 및 과금 측정들 하에서 과금될 수 있다. 서비스 계층은 애플리케이션에 전달되는 콘텐츠 및 컨텍스트 정보, 즉 서비스 인식(service-awareness)을 더 차별화할 수 있다. 따라서, 서비스 계층 과금은 전송 네트워크의 과금 메커니즘보다 더 유연할 수 있다.

그러나, 현재 서비스 계층 과금 메커니즘들은 이러한 유연성을 가능하게 하기에 충분하지 않다. 수집할 정보가 무엇인지, 요구되는 컨텍스트 정보를 어떻게 수집할지, 및 이 정보를 청구서 작성 시스템에 어떻게 전달할지는 아직 정의되지 않았다. 오프라인 과금에 대해서도, 청구서 작성 도메인은 결정을 내리는 것을 담당하지만, 청구서 작성 도메인은 여전히 서비스 계층 플랫폼(1102)에서 수집되어 그로부터 전해지는 서비스 컨텍스트에 의존한다.

추가로, 실시간 결정을 요구하는 서비스 계층 온라인 과금을 구현하기 위해, 요금율 정보를 구성하는 방법과 요금율 기능성을 포함하여 온라인 과금을 수행하는 방법은 정의되어 있지 않다. 이러한 메커니즘들 및 필요한 정보 요소들이 없으면, 기저 네트워크 과금 시스템에 독립적인 서비스 계층 플랫폼(1102) 내에서 온라인 과금을 수행하는 것은 어렵다.

유연한 과금 서비스를 위한 기능적 아키텍처

본 출원의 양태에 따라, 유연한 서비스 계층 과금을 가능하게 하기 위한 아키텍처, 절차들, 및 파라미터들이 제공된다. 제시된 아키텍처 및 절차들은 다른 서비스 계층 시스템들에 일반적이다. 리소스 및 프리미티브들에 포함된 파라미터들은 oneM2M 용어들로 제시된다. 3GPP는 기저 네트워크와의 유연한 서비스 계층 과금의 아키텍처를 설명하기 위한 예로서 보여진다. 이 섹션에서 제시된 아키텍처 및 절차들은 다른 유형들의 기저 네트워크에도 적용될 수 있음이 예상된다.

도 12는 서비스 계층 청구서 작성 도메인을 포함하는 서비스 계층 오프라인 과금 시스템의 아키텍처를 도시한다. 3GPP 오프라인 과금 시스템은 서비스 계층과 기저 네트워크 사이에서 과금 상관이 수행될 수 있는 방법을 보여주는 예로서 포함된다. 과금 정보와 다른 유형들의 기저 네트워크들(예를 들어, 광대역 네트워크 등)과의 상관을 수행하는 것이 가능하다는 점에 유의해야 한다. 서비스 계층 과금 서비스는 도 12에 도시된 이하의 로직 기능부들에 의해 제공된다.

● 서비스 도메인 과금 트리거링 기능부(SD-CTF)(1202)는 상이한 서비스들에 대한 다양한 과금가능한 이벤트들을 검출하고, 이벤트(들)가 언제 발생하는지를 검출하고, 이벤트(들)에 관한 정보를 수집하고, 이벤트의 발생 및 관련된 세부사항들을 SD-CDF에 보고하도록 구성될 수 있다.

● 서비스 도메인 과금 데이터 기능부(SD-CDF)(1204)는 SD-CTF(1202)로부터 과금 이벤트 정보를 수신할 때 CDR들을 생성하는 것을 담당한다.

● 서비스 도메인 과금 게이트웨이 기능부(SD-CGF)(1206)는 서비스 계층과 서비스 계층 청구서 작성 도메인(1208) 사이의 게이트웨이의 역할을 한다. 일단 CDR들이 SD-CDF에서 생성되면, 그것들은 SD-CGF(1206)에 전해질 것이다. SD-CGF(1206)는 이하의 기능들을 수행할 수 있다:

○ CDR들의 처리, 예를 들어 CDR 유효성 검사: CDR이 미리 정의된 형식을 따르는지, CDR이 요구되는 정보를 포함하는지, CDR 내의 일부 파라미터들이 유효하고 적절한지를 체크하는 것을 포함함.

○ CDR 파일들을 생성하고 CDR 파일들을 서비스 청구서 작성 도메인(1208)에 전달한다.

서비스 도메인 과금 트리거링 기능부들(SD-CTF)(1202, 1210 및 1212)은 과금 이벤트들을 캡처하기 위해 상이한 유형들의 CSE[즉, ASN-CSE(1220), MN-CSE(1222) 및 IN-CSE(1224)]에 상주할 수 있는 한편, 서비스 도메인 과금 데이터 기능부(SD-CDF)(1204) 및 서비스 도메인 과금 게이트웨이 기능부(SD-CGF)(1206)는 각각 CDR 및 CDR 파일들을 생성하기 위해 IN-CSE(1224)(즉, 기반구조 도메인 내의 서버)에만 상주하는 것으로 가정된다.

오프라인 과금 아키텍처는 이하의 배치 시나리오들을 커버한다:

● 시나리오 1: 서비스 계층이 기저 네트워크(예를 들어, 3GPP)로부터의 어떠한 도움도 없이 오프라인 과금을 할 수 있도록, 서비스 계층은 서비스 청구서 작성 도메인(1208)뿐만 아니라 완전하고 독립적인 오프라인 과금 시스템[즉, SD-CTF(1202), SD-CDF(1204) 및 SD-CGF(1206)]을 갖는다. 과금 이벤트 및 통계 수집 정보는 서비스 제공자 또는 애플리케이션에 의해 구성될 수 있다. CSE 내의 SD-CTF는 과금 이벤트의 세부사항들을 모니터링하고 캡처하는 것을 담당한다.

● 시나리오 2: 서비스 계층은 SD-CDF/SD-CGF 및 청구서 작성 시스템을 갖지 않는 한편, 과금 정보를 캡처하고 보고하는 SD-CTF(1202)만을 갖는다. 서비스 계층 과금은 기저 네트워크 내의 과금 시스템, 예를 들어 3GPP OFCS 및 청구서 작성 시스템에 의존한다. 따라서, SD-CTF들은 SCEF(1226)(oneM2M 용어로 NSSE)를 통해 3GPP OFCS에 서비스 계층 과금 이벤트 정보를 송신한다. SCEF(1226)가 없는 CSE(예를 들어, 홈 게이트웨이, oneM2M 용어로 MN/ASN-CSE)에 대해, 수집된 과금 이벤트 정보는 SCEF 능력을 갖는 트랜짓 CSE에 전해진다.

도 12에 도시된 기능성은 이하에 설명되는 도 22c 또는 도 22d에 도시된 것들과 같은 무선 디바이스, 또는 다른 장치(예를 들어, 서버, 게이트웨이, 디바이스, 또는 다른 컴퓨터 시스템)의 메모리 내에 저장되고 그것들의 프로세서 상에서 실행되는 소프트웨어(즉, 컴퓨터 실행가능한 명령어들)의 형태로 구현될 수 있다. 또한, 도 12에 도시된 기능성은 가상화된 네트워크 기능부들의 세트로서 구현될 수 있다. 네트워크 기능부들은 반드시 직접 통신하지는 않을 수 있으며, 오히려 포워딩 또는 라우팅 기능부를 통해 통신할 수 있다.

실시예에서, 도 13은 서비스 계층 청구서 작성 도메인(1208)을 갖는 서비스 계층 온라인 과금 시스템의 기능적 아키텍처를 도시한다. 3GPP OCS는 온라인 과금을 위해 서비스 계층과 기저 네트워크 사이에서 과금 상관이 수행될 수 있는 방법을 보여주는 예로서 도시된다.

오프라인 과금을 위해 배치된 기능성들과 비교하여, 이하의 새로운 논리적 기능성들이 배치되어 서비스 계층 온라인 과금을 용이하게 한다:

● SD-CTF(1202)의 새로운 기능성:

○ 발원자로부터의 요청에 기초하여 요금율 계산을 트리거하기 위해 서비스 도메인 요금율 기능부(SD-RF)(1302)와 상호작용한다.

○ 발원자가 요청된 대로 서비스를 제공할 충분한 크레디트를 갖는지를 검증하기 위해 서비스 도메인 계정 및 잔액 관리 기능부(SD-ABMF)(1304)와 상호작용하고, SD-ABMF(1304)에게 계정을 예약 및 업데이트할 것을 요청한다.

○ 서비스 전달 동안 실시간으로 리소스 사용을 모니터링하고 추적한다.

○ 승인된 리소스/유닛들이 모두 소모되거나 만료된 경우 서비스 전달을 중단하거나, 승인된 리소스가 모두 소모된 때 서비스 전달을 계속하도록 승인된 더 많은 리소스를 얻기 위해, SD-RF(1302) 및 SD-ABMF(1304)와 통신한다.

● 서비스 도메인 요금율 기능부(SD-RF)(1302): 온라인 과금 이벤트에 사용되어야 하는 요금율 체계를 식별하고, 요청된 서비스를 사용하기 위한 비용을 계산한다. SD-CTF(1202)는 과금 이벤트에 관한 필요한 정보를 제공하고, SD-RF(1302)로부터 요금율 출력(서비스 유닛들 및 금전적 비용의 요구되는 양)을 수신하며, 이는 2개의 주요 기능을 포함한다:

○ 유닛 결정: 발원자에 대한 서비스 전달을 시작하기 전에 할당되어야 하는 비-금전적 유닛들(서비스 유닛들, 데이터 용량, 시간 및 이벤트들)의 수를 계산

○ 가격 결정(즉, 요금율): 유닛 결정에 의해 계산된 비-금전적 유닛들로부터 가격을 계산.

● 서비스 도메인 계정 및 잔액 관리 기능부(SD-ABMF)(1304): 가입자의 계정 잔액을 유지 및 관리.

도 12 및 도 13은 기능적 아키텍처를 도시한다. 이것은 구현 관점이 아니다. 실시예에 도시된 아키텍처는 시스템을 어떻게 구축하는지를 나타낼 것이다. 더욱이, 서비스 계층과 기저 전송 네트워크 사이의 과금 상관(연동)은 도면들 둘 다에 도시된다. 3GPP 네트워크는 예시적인 기저 네트워크이다.

도 12에 도시된 기능성은 이하에 설명되는 도 22c 또는 도 22d에 도시된 것들과 같은 무선 디바이스, 또는 다른 장치(예를 들어, 서버, 게이트웨이, 디바이스, 또는 다른 컴퓨터 시스템)의 메모리 내에 저장되고 그것들의 프로세서 상에서 실행되는 소프트웨어(즉, 컴퓨터 실행가능한 명령어들)의 형태로 구현될 수 있다. 또한, 도 13에 도시된 기능성은 가상화된 네트워크 기능부들의 세트로서 구현될 수 있다. 네트워크 기능부들은 반드시 직접 통신하지는 않을 수 있으며, 오히려 포워딩 또는 라우팅 기능부를 통해 통신할 수 있다.

서비스 계층 오프라인 과금을 위한 절차들

다른 실시예에서, 도 14에 예시적으로 도시된 바와 같이, 오프라인 과금 시스템의 호출 흐름은 '서비스 계층 가입 생성'을 오프라인 과금 이벤트로 고려한다. 두 가지 시나리오가 커버된다:

도 14의 단계(1) 내지 단계(8)에서, 애플리케이션 1(1402)은 M2M 서버(1404)에서 가입을 생성하라는 요청을 M2M 서버(1404)에 등록한다.

상세한 단계들은 이하와 같이 설명된다:

도 14의 단계(1) 내지 단계(3)에서, 애플리케이션 1(1402)은 M2M 서버의 특정 콘텐츠에 대한 가입을 생성하기 위해, M2M 서버와 요청 및 응답을 교환한다.

도 14의 단계(4)에서, SD-CTF(1202)는 콘텐츠에 대한 가입 생성이 제공자에 의한 오프라인 과금 이벤트로서 구성됨을 검출하고, 따라서 새로운 가입 정보에 관한 요구되는 정보, 즉 과금 이벤트 정보를 수집한다. SD-CTF(1202)와 가입/통지 서비스 사이의 상호작용이 존재한다. 구체적으로, 가입/통지 서비스는 SD-CTF(1202)에게 생성된 새로운 가입이 있다는 것을 통지할 것이므로, SD-CTF(1202)는 가입 생성이 과금 이벤트로서 구성되는지를 결정할 것이다.

도 14의 단계(5)에서, SD-CDF(1204)는 SD-CTF(1202)로부터 수집되고 제공되는 새로운 가입 정보에 기초하여 CDR을 생성함으로써 내부적으로 트리거된다.

도 14의 단계(6)에서, SD-CGF(1206)는 CDR을 처리하고 CDR 파일들에 CDR들을 추가한다.

도 14의 단계들(7 및 8)에서 SD-CGF(p1206)는 새로운 CDR 파일들을 서비스 계층 청구서 작성 시스템에 전달한다. 가입 생성의 이벤트에 관련된 CDR은 이하의 정보를 포함할 수 있다:

○ 과금 레코드 유형

○ 기록 엔티티 ID

○ 소스 엔티티 ID

○ 타겟 엔티티 ID

○ 과금 이벤트 유형

○ 과금 유형

○ CDR 시퀀스 번호

○ M2M 가입 ID

○ M2M 외부 ID

○ 기저 네트워크 ID

○ 가입 제한

도 14의 단계(9) 내지 단계(16)에서, 애플리케이션 2(1406)는 M2M 서버에 가입을 생성하라는 요청들을 M2M 게이트웨이에 등록한다. 도 14의 단계(9)는 도 14의 단계(1) 내지 단계(3)의 동작들을 반복한다는 점에 유의해야 한다.

도 14의 단계(9)에서, 애플리케이션 2(1406)는 단계(1) 내지 단계(3)를 반복함으로써 M2M 서버(1404)에서 가입을 생성한다.

도 14의 단계(10)는 단계(4)와 유사한 동작이다.

도 14의 단계(11)에서, M2M 게이트웨이(1408) 내의 SD-CTF(1202)는 CDR 생성을 위해 과금 이벤트 전달 요청 메시지를 M2M 서버(1404) 내의 SD-CDF(1202)로 송신한다. 요청 메시지는 이하의 정보를 포함할 수 있다:

○ 이벤트 식별: 이러한 과금 프로세스를 트리거하는 과금 이벤트를 나타낸다. 이벤트 식별을 통해, 과금 이벤트의 유형, 동작의 유형, 이벤트에 대해 과금되어야 하는 엔티티들의 식별과 같은 더 많은 정보가 획득될 수 있다.

○ 통계 수집 정보: SD-CTF(1202)에 의해 수집된 과금 이벤트 정보, 예를 들어 이벤트 정보가 수집된 때의 타임 스탬프, 가입을 생성하기를 요청하는 애플리케이션의 ID, 가입의 유형 및 통지 조건, 가입 ID의 목록을 포함한다.

도 14의 단계(12)에서, M2M 서버 내의 SD-CDF는 과금 이벤트 전달 응답을 리턴하여, 그것이 수집된 과금 이벤트 정보를 성공적으로 수신했음을 확인한다.

도 14의 단계(13) 내지 단계(16)은 단계(5) 내지 단계(8)와 동일하다.

'과금 이벤트 전송' 요청/응답 메시지에 관한 더 상세한 내용은 이하에 제시된다. 도 14에 도시된 단계들을 수행하는 엔티티들은 도 22c 또는 도 22d에 도시된 것들과 같은 컴퓨터 시스템 또는 무선 및/또는 네트워크 통신들을 위해 구성된 장치의 메모리 내에 저장되고 그것들의 프로세서 상에서 실행되는 소프트웨어(즉, 컴퓨터 실행가능한 명령어들)의 형태로 구현될 수 있는 논리적 엔티티들일 수 있다. 즉, 도 14에 도시된 방법(들)은 도 22c 또는 도 22d에 도시된 컴퓨터 시스템 또는 장치와 같은 장치의 메모리에 저장된 소프트웨어(즉, 컴퓨터 실행가능한 명령어들)의 형태로 구현될 수 있고, 그것의 컴퓨터 실행가능한 명령어들은 장치의 프로세서에 의해 실행될 때 도 14에 도시된 단계들을 수행한다. 도 14에 도시된 기능성은 가상화된 네트워크 기능부들의 세트로서 구현될 수 있다. 네트워크 기능부들은 반드시 직접 통신하지는 않을 수 있으며, 오히려 포워딩 또는 라우팅 기능부를 통해 통신할 수 있다. 도 14에 도시된 임의의 송신 및 수신 단계들은 장치의 프로세서, 및 그것이 실행하는 컴퓨터 실행가능한 명령어들(예를 들어, 소프트웨어)의 제어 하에서 장치의 통신 회로에 의해 수행될 수 있다.

요금율 기능부를 사용하는 서비스 계층 온라인 과금을 위한 절차

본 출원의 다른 양태에 따르면, 요금율 기능부(rating function)를 사용하는 서비스 계층 온라인 과금을 위한 절차가 설명된다. 예시적인 실시예에서, 도 15는 M2M 게이트웨이(1408)에 등록되는 애플리케이션(1502)에 의한 온라인 과금 이벤트에 대한 요금율 정보/체계를 구성하는 절차를 도시한다. 또한, 애플리케이션이 M2M 서버(1404)에 직접 등록하거나, 서비스 제공자(즉, CSE)가 이 요금율 정보를 구성한다는 점에 유의해야 한다. 이 도면에서, M2M 서버(1404)는 SD-CTF(1202)를 포함하고; M2M 게이트웨이(1408)는 SD-CTF(1504)를 포함한다. 상세한 단계들은 아래에서 다음과 같이 설명된다:

도 15의 단계(1)에서, 애플리케이션(1502)은 '요금율 구성 요청(configure rating request)' 메시지를 M2M 게이트웨이(1408)에 송신하고, M2M 게이트웨이는 요청을 M2M 서버(1404)에 포워딩한다. 요청 메시지는 요금율 정보에 관한 이하의 파라미터들을 포함할 수 있다:

○ 온라인 과금 이벤트에 대한 참조: 온라인 과금 이벤트와 이러한 요금율 정보 사이의 링크를 구축하기 위해 사용된다. 즉, 이는 이러한 요금율 정보/체계가 어느 온라인 과금 이벤트에 적용되는지를 나타낸다.

○ 이러한 요금율 체계가 적용되는 애플리케이션들의 목록: 제공자가 이러한 요금율 정보를 사용하여 과금하기를 원하는 애플리케이션들(즉, 사용자들)의 목록을 제공한다.

○ 온라인 과금 시나리오: 온라인 과금 이벤트 및 요금율 체계의 조합에 관하여 어느 온라인 과금 시나리오(즉, 예약 기반 또는 이벤트 기반)가 사용되는지를 나타낸다. 이벤트의 예는 리소스 판독(검색) 또는 기입(생성/업데이트) 동작일 수 있다.

○ 서비스 유닛 측정: 엔티티가 과금의 기초로 할 서비스 유닛(예를 들어, 용량, 시간, 트랜잭션)을 나타낸다. 동일한 과금 이벤트에 대해, 상이한 애플리케이션들/사용자들은 상이한 유형들의 유닛들로 과금될 수 있음에 유의해야 한다.

○ 서비스 유닛 당 비용: 온라인 과금 이벤트에 대한 서비스 유닛에 관한 가격(즉, 금전적 비용)을 나타낸다.

요금율 구성은 과금 이벤트 및 통계 수집 구성과는 별도의 단계를 통해 수행 될 수 있으며, 과금 이벤트 및 통계 수집의 구성이 완료된 후에 수행될 수 있음에 유의해야 한다.

도 15의 단계(2)에서, M2M 서버(1404)는 요청 메시지를 수신하면 이 요금율 정보를 내부적으로 저장한다.

도 15의 단계(3)에서, '요금율 구성 응답' 메시지가 발원자, 즉 애플리케이션(1502)에 리턴된다.

'요금율 구성' 요청/응답 메시지에 관한 더 상세한 내용은 이하에 제시된다.

도 15에 도시된 단계들을 수행하는 엔티티들은 도 22c 또는 도 22d에 도시된 것들과 같은 컴퓨터 시스템 또는 무선 및/또는 네트워크 통신들을 위해 구성된 장치의 메모리 내에 저장되고 그것들의 프로세서 상에서 실행되는 소프트웨어(즉, 컴퓨터 실행가능한 명령어들)의 형태로 구현될 수 있는 논리적 엔티티들일 수 있다. 즉, 도 15에 도시된 방법(들)은 도 22c 또는 도 22d에 도시된 컴퓨터 시스템 또는 장치와 같은 장치의 메모리에 저장된 소프트웨어(즉, 컴퓨터 실행가능한 명령어들)의 형태로 구현될 수 있고, 그것의 컴퓨터 실행가능한 명령어들은 장치의 프로세서에 의해 실행될 때 도 15에 도시된 단계들을 수행한다. 도 15에 도시된 기능성은 가상화된 네트워크 기능부들의 세트로서 구현될 수 있음이 이해된다. 네트워크 기능부들은 반드시 직접 통신하지는 않을 수 있으며, 오히려 포워딩 또는 라우팅 기능부를 통해 통신할 수 있다. 또한, 도 15에 도시된 임의의 송신 및 수신 단계들은 장치의 프로세서, 및 그것이 실행하는 컴퓨터 실행가능한 명령어들(예를 들어, 소프트웨어)의 제어 하에서 장치의 통신 회로에 의해 수행될 수 있음이 이해된다.

요금율 기능부를 사용하는 예약 기반 온라인 과금

또 다른 양태에 따르면, 도 16에 예시적으로 도시된 바와 같이, 예약 기반 서비스 계층 온라인 과금의 절차가 설명된다. 여기서, 서비스 유닛들은 성공적인 서비스 전달에 대해 승인되고 충분하다. 상세한 단계들은 이하와 같이 설명된다:

도 16의 단계(1)에서, 애플리케이션(1502)은 특정 동작, 예를 들어 CRUD에 대한 요청을 송신한다.

도 16의 단계(2)에서, M2M 게이트웨이(1408)는 요청된 동작이 온라인 과금 이벤트로서 구성됨을 식별한다. 이를 달성하기 위해, M2M 게이트웨이(1408)는 자신의 데이터베이스에서 구성되고 유지되는 과금 이벤트들을 요청 메시지 내에 운반된 정보와 비교할 수 있다. M2M 게이트웨이(1408)에 상주하는 SD-CTF는 이러한 동작을 수행하는 것을 담당한다. 그 전에, M2M 게이트웨이 내에서 SD-CTF와 가입/통지 서비스 사이의 내부 상호작용이 존재한다. 구체적으로, SD-CTF는 요청이 수신된다는 통지를 받고, 다음으로 SD-CTF는 요청 메시지에 관한 과금 이벤트를 식별하려고 시도한다.

도 16의 단계(3)에서, 온라인 과금 이벤트를 식별한 후, M2M 게이트웨이(1408)는 요청 메시지의 처리를 중지하고, M2M 서버(1402)에 상주한다고 가정되는 SD-RF(1302)에 요금율 요청 메시지를 송신한다. 요금율 요청 메시지는 이하의 정보를 포함할 수 있다:

○ 온라인 과금 이벤트 이름 또는 ID

○ 애플리케이션 식별

○ 요청된 동작 또는 서비스들

○ 요청된 동작/서비스가 있다면, 그것의 요구되는 수량

도 16의 단계(4)에서, 요금율 요청을 수신하고 나면, 요금율 기능부는 어느 요금율 체계를 이용할지 결정한다. 애플리케이션들은 동일한 온라인 과금 이벤트에 대해 상이한 요금율 체계들 하에서 과금될 수 있으므로, 요금율 기능부는 온라인 과금 이벤트 정보(예를 들어, 온라인 과금 이벤트 리소스에 대한 참조), 애플리케이션 식별, 및 요청된 동작/서비스를 적용하여 결정을 내린다. 요금율 체계가 결정되면, 요금율 기능부는 발원자로부터의 요청된 동작들/서비스들에 기초하여 서비스 유닛들 및 실제 비용의 요구되는 양을 계산한다.

도 16의 단계(5)에서, 요금율 기능부는 M2M 게이트웨이(1408)에 서비스 유닛들 및 실제 비용의 요구되는 양을 리턴한다.

다음으로, 도 16의 단계(6)에서, M2M 게이트웨이(1408)는 요구된 비용에 대해 애플리케이션의 계정에 충분한 크레디트가 존재하는지를 확인하기 위해, 계정 잔액 및 관리 기능부에 '계정 크레디트 체크' 요청을 송신한다. 이 요청 메시지에는 이하의 정보를 포함할 수 있다:

○ 요금율 기능부에 의해 계산되고 리턴된 서비스 유닛들 및 비용의 요구되는 양.

○ 애플리케이션 ID: 이것은 계정을 식별하기 위해 서비스 제공자 ID와 함께 사용된다.

○ 애플리케이션의 외부 ID: 이것은 애플리케이션의 외부 ID가 이용가능할 때에만 포함된다. 이 외부 ID는 애플리케이션 ID로 변환될 것이다.

○ 서비스 제공자 ID 또는 서비스 계층 플랫폼 운영자 ID: 이것은 계정을 식별하기 위해 애플리케이션 ID와 함께 사용된다.

이 단계는 단계(4)와 함께 수행될 수 있다. 즉, SD-RF(1302)는 하나의 단계에서 요금율을 계산하고 크레디트 정보를 체크할 수 있다. 그렇다면, 단계(6) 및 단계(7)은 각각 단계(4) 및 단계(5)와 결합된다.

도 16의 단계(7)에서, 애플리케이션은 상이한 서비스 제공자들과의 상이한 계정들을 가질 수 있으므로, SD-ABMF(1604)는 먼저 애플리케이션 ID, 및 서비스 제공자/서비스 계층 플랫폼 운영자 ID를 고려하여 계정을 식별할 필요가 있다. 계정이 식별되면, SD-ABMF(1604)는 '계좌 크레디트 체크' 요청에 포함된 실제 비용을 비교함으로써, 애플리케이션이 서비스 전달을 제공하기에 충분한 크레디트를 갖는지를 결정한다.

도 16의 단계(8)에서, 애플리케이션이 요청된 대로 서비스 전달을 제공하기에 충분한 크레디트를 갖는지를 나타내기 위해, '계좌 크레디트 체크' 응답이 리턴된다. 그렇다면, M2M 게이트웨이는 단계(9)를 시작하고; 그렇지 않다면, M2M 게이트웨이는 단계(1) 요청이 불충분한 크레디트로 인해 거절됨을 나타내기 위해 발원자(즉, 애플리케이션)에 응답을 송신함으로써 단계(12)로 진행한다.

단계들(9 내지 11)에서, M2M 게이트웨이(1408)는 서비스 전달을 시작하기 전에 크레디트를 예약하기 위해 SD-ABMF(1604)에 '계정 업데이트 및 크레디트 예약' 요청을 송신한다. 요청에서, 게이트웨이는: 1. 그것이 SD-ABMF(1604)에 업데이트 대신 일부 크레디트를 예약하도록 요청한다는 것; 2. 예약될 크레디트의 양을 나타낼 필요가 있다.

SD-ABMF(1604)는 크레디트를 예약하고, 확인을 위해 응답을 리턴한다. 단계들(9 내지 11)이 단계들(6 내지 8)과 각각 조합하여 수행되는 것이 가능하다. 이러한 의미에서, 단계(6)을 통해 송신된 요청은 단계(9) 요청과 결합되고, 따라서 요청들 둘 다에 포함된 정보가 통합된다.

일반적으로, 단계들(3 내지 11)은 하나의 요청/응답 교환으로서 통합되거나 병합될 수 있고, 여기서 요금율 계산 및 계정 관리 동작들은 하나의 동작으로 수행될 수 있다.

단계(12)에서, M2M 게이트웨이(1408)는 서비스 유닛들이 승인됨을 나타내기 위한 응답을 애플리케이션에 리턴하고, 요청이 수락되거나; 요청이 원인 코드와 함께 거절된다.

단계(13)에서, M2M 게이트웨이(1408) 내의 SD-CTF는 서비스 전달 동안 승인된 서비스 유닛들의 사용을 모니터링한다. 승인된 서비스 유닛들이 서비스 전달의 종료 전에 모두 소모되면, M2M 게이트웨이(1408)는 서비스 전달을 일시 정지하고, 요금율 기능부에 접촉하여 단계(3)으로부터 온라인 과금 프로세스를 반복한다. 이 단계는 임의적(optional)이다. 요청된 동작이 즉시 완료되는 경우, 이 단계는 서비스 전달 단계로 병합될 수 있다.

단계들(14 내지 16)에서, 서비스 전달이 성공적으로 종료될 때, M2M 게이트웨이(1408)는 서비스 유닛들 및 금전적 비용의 실제 사용을 추정하고, 애플리케이션의 계정을 업데이트하기 위해 SD-ABMF(1604)에 요청을 송신한다. '요금율' 요청/응답 메시지는 아래에 더 상세히 설명된다.

도 16에 도시된 단계들을 수행하는 엔티티들은 도 22c 또는 도 22d에 도시된 것들과 같은 컴퓨터 시스템 또는 무선 및/또는 네트워크 통신들을 위해 구성된 장치의 메모리 내에 저장되고 그것들의 프로세서 상에서 실행되는 소프트웨어(즉, 컴퓨터 실행가능한 명령어들)의 형태로 구현될 수 있는 논리적 엔티티들일 수 있다. 즉, 도 16에 도시된 방법(들)은 도 22c 또는 도 22d에 도시된 컴퓨터 시스템 또는 장치와 같은 장치의 메모리에 저장된 소프트웨어(즉, 컴퓨터 실행가능한 명령어들)의 형태로 구현될 수 있고, 그것의 컴퓨터 실행가능한 명령어들은 장치의 프로세서에 의해 실행될 때 도 16에 도시된 단계들을 수행한다. 도 16에 도시된 기능성은 가상화된 네트워크 기능부들의 세트로서 구현될 수 있다. 네트워크 기능부들은 반드시 직접 통신하지는 않을 수 있으며, 오히려 포워딩 또는 라우팅 기능부를 통해 통신할 수 있다. 또한, 도 16에 도시된 임의의 송신 및 수신 단계들은 장치의 프로세서, 및 그것이 실행하는 컴퓨터 실행가능한 명령어들(예를 들어, 소프트웨어)의 제어 하에서 장치의 통신 회로에 의해 수행될 수 있음이 이해된다.

본 출원은 또한 예약 기반 온라인 과금에 대한 소정의 다른 가능한 시나리오를 예상한다. 예를 들어, 승인된 서비스 유닛들이 충분하지 않은 경우, SD-CTF는 서비스 전달을 일시 중지하고, 서비스 전달을 계속하기 위해 더 많은 서비스 유닛을 요청할 수 있다. 대안적으로, 애플리케이션의 계정에 크레디트가 불충분한 것으로 인해 요청이 거절된다. 다른 대안적인 실시예에서, 서비스 프로비저닝의 특정 파라미터들(예를 들어, QoS 파라미터들)이 변경되기 때문에, 서비스 전달 동안 요금율이 변경된다. 일반적으로, 이러한 시나리오들은 약간 다른 절차를 필요로 하지만, 주요 흐름은 도 16에 도시된 것과 유사하다.

새로운 리소스들 및 속성들

또 다른 실시예에 따르면, 과금 관점에서, <eventConfig> 리소스는 일련의 과금 활동들을 트리거할 수 있는 과금 이벤트를 정의하기 위해 사용될 수 있다. 또한, <eventConfig> 리소스는 과금 이벤트를 수집하고 보고하기 위해 충족되도록 기대되는 일부 조건들을 지정한다. 즉, <eventConfig> 리소스는 일부 조건들(예를 들어, eventStart, eventEnd 및 dataSize 속성)을 갖는 미리 정의된 과금 이벤트를 표현한다.

유연한 서비스 계층 과금을 가능하게 하기 위해, 본 개시내용은 더 많은 서비스 컨텍스트를 고려하여 과금 이벤트들의 유형들을 더 구별하기 위해 2개의 새로운 속성을 <eventConfig>에 추가한다. 표 1은 새로운 속성을 설명한다. 표 2는 값들의 목록이기 때문에 'eventCriteria' 속성에 포함될 수 있는 가능한 조건들을 나열한다.

chargingEventType 속성이 없으면, 온라인 또는 오프라인 과금 모델이 이벤트에 적용되어야 하는지 결정하는 것이 가능하지 않을 것이다. eventCriteria 속성이 없으면, 이벤트 구성이 요청 개시자, 리소스의 유형, 또는 리소스 위치에 의존하게 하는 것이 가능하지 않을 것이다.

다른 실시예에 따르면, <statsCollect> 리소스는 <eventConfig>를 통해 참조된 주어진 과금 이벤트에 대한 정보 수집을 트리거하는 정보가 무엇인지뿐만 아니라 일부 조건들을 정의한다. 새로운 속성은 주어진 과금 이벤트에 대해 수집할 정보가 무엇인지를 더 정의한다. 표 3은 새로운 속성을 나타내고, 표 4는 새로운 속성 목록에 포함된 수 개의 가능한 파라미터를 나열한다. 'statsToCollect' 속성 내의 파라미터들은 커스터마이즈되는데, 즉 서비스 제공자 또는 과금을 담당하는 엔티티에 의해 구성된다.

다른 실시예에 따르면, 수집된 과금 정보를 저장하기 위한 새로운 <statsRecord> 리소스가 설명된다. 이것은 서비스 계층 CDR로 고려될 수 있다. 일반적으로, 이러한 새로운 리소스 내의 속성들은 <statsCollect> 리소스 내의 'statsToCollect' 속성에 의해 지정된 정보와 유사해야 한다.

표 5는 새로운 <statsRecord> 리소스의 속성들 및 자식 리소스를 보여주며, 이는 <CSEBase> 리소스 아래에 생성되고 유지될 수 있다.

다른 실시예에 따르면, 새로운 <serviceRating> 리소스는 온라인 과금 절차 동안 요금율 프로세스를 위해 사용된다. 이러한 새로운 리소스는 서비스 계층 온라인 과금을 위해 정의되어 사용된다. 표 6은 <serviceRating> 리소스의 속성을 보여준다.

동일하거나 상이한 엔티티들에 의해 온라인 과금 이벤트에 대해 정의되는 복수의 요금율 규칙이 존재할 수 있으므로, 특정 애플리케이션 또는 사용자에게 적용되어야 하는 요금율 규칙을 고유하게 식별하기 위해 creatorID 및 chargedEntityID와 함께 eventID가 사용될 수 있다. 추가로, 서비스 가입 정보(예를 들어, 가입 ID) 및/또는 자격증명 정보(예를 들어, 자격증명 ID)는 온라인 과금 이벤트 및 애플리케이션을 요금율 방법/체계와 링크하기 위해 사용된다.

새로운 <accountInfo> 리소스가 정의되고, 서비스 계층 온라인 과금에 대한 계정 관리를 위해서만 사용된다. 이것은 사용자/클라이언트의 계정 정보를 유지하여, 온라인 과금 프로세스가 계정 잔액을 체크하고 서비스 사용을 위해 크레디트를 업데이트/예약할 수 있도록 하기 위해 사용된다. 표 7은 <accountInfo> 리소스의 속성들을 보여준다.

accountID 및 entityID 속성들은 계정을 고유하게 식별하는데, 이는 엔티티(예를 들어, 애플리케이션)가 상이한 서비스 제공자들 하에서 상이한 계정들을 가질 수 있음을 암시한다는 점에 유의해야 한다.

새로운 가상 리소스들

다른 실시예에 따르면, 이하의 2개의 가상 리소스가 사용될 수 있다:

● <rateCalculation>: 온라인 과금 프로세스의 일부로서 서비스 전달을 위해 요구되는 서비스 유닛들 및 비용을 계산하기 위해 요금율 기능부를 트리거한다.

● <accountManagement>: 온라인 과금 프로세스의 일부로서 계정 잔액 관리(예를 들어, 업데이트, 크레디트 예약)를 트리거한다.

이것은 이러한 2개의 가상 리소스가 대응하는 온라인 과금 활동에만 수반되며 리소스 트리 내에 표현을 갖지 않음을 암시한다.

새로운 과금 이벤트 전송 요청 프리미티브는 새로운 과금 이벤트에 관한 CDR이 생성되도록 과금 이벤트의 발생을 SD-CDF에 보고하기 위해 SD-CTF에 의해 사용된다. 표 8은 과금 이벤트 전송 요청의 인터페이스 적용가능성을 보여준다. 표 9는 과금 이벤트 전송 요청 내의 일부 파라미터들을 보여준다.

과금 이벤트 전송 응답은 타겟 엔티티가 과금 이벤트 전송 요청 메시지를 성공적으로 수신하는지 확인하기 위해 사용된다. 과금 이벤트 전송 응답의 인터페이스 적용가능성은 표 10에 보여진다.

요금율 구성 요청은 온라인 과금 이벤트를 위해 사용될 요금율 체계를 구성하기 위해 사용된다.

요금율 구성 응답은 수신 엔티티가 요금율 구성 요청 메시지를 성공적으로 수신하는 것을 확인하기 위해 사용된다.

요금율 요청은 요금율 기능부를 트리거하여 발원자에 의해 요청된 서비스 전달을 지원하기 위해 요구되는 비용을 계산하기 시작하는 데 사용된다.

요금율 응답은 요금율 기능부가 요금율 요청 메시지를 성공적으로 얻는 것을 확인하고, 요구되는 서비스 유닛들 및 금전적 비용을 다시 전달하기 위해 사용된다.

다른 실시예에서, 도 17은 복수의 배치 시나리오를 커버하는 OMB 시스템 내의 서비스 계층 과금 서비스를 구현하기 위한 아키텍처를 도시한다. 각각의 논리적 기능부(예컨대, SD-CTF)는 복수 부분의 기능부/서비스를 통해 구현될 수 있음에 유의해야 한다. 범례에 표시된 바와 같이, 서비스들의 일부 부분들(예를 들어, 과금 이벤트 구성, CDR 생성 및 전송)은 오프라인 및 온라인 과금 둘 다에 유효하지만, 다른 것들(예를 들어, 요금율, 유닛 단위/가격 구성)은 온라인 과금에만 유효하다.

이 섹션은 도 17에 도시된 서비스들/기능부들의 각각의 부분에 대한 추가의 세부사항들을 기술한다. '과금 이벤트 구성' 서비스(1702)는 과금 이벤트 및 통계 수집 정보, 즉 과금 이벤트에 대해 어떤 정보를 수집할지를 구성하는 것을 담당한다. 그것은 오프라인 및 온라인 과금 둘 다에 대해 SD-CTF를 구현하는 기능부의 부분이다. 그것은 CSF/서비스 특정적이다. 즉, 각각의 서비스(예를 들어, 보안, 그룹 관리, 디바이스 관리)는 자기 자신의 과금 이벤트를 개별적으로 구성한다. 과금 이벤트들은 상이한 서비스들 사이에서 크게 달라진다. 이 서비스는 서비스 제공자가 과금 이벤트 및 통계 수집 정보를 구성(즉, 생성, 업데이트 및 삭제)하기를 원할 때 언제든지 호출될 수 있다.

'과금 이벤트 검출' 서비스(1704)는 동작이 수행될 때 임의의 구성된 과금 이벤트가 발생하는지를 검출하기 위해 사용된다. 오프라인 및 온라인 과금 둘 다에 대해 SD-CTF를 구현하는 기능부의 부분이다.

'과금 이벤트 보고' 서비스(1706)는 과금 이벤트의 발생이 식별될 때 SD-CDF에 과금 이벤트 정보를 수집하고 보고하는 것을 담당한다. 오프라인 및 온라인 과금 둘 다에 대해 SD-CTF를 구현하는 기능부의 부분이다.

　'CDR 생성 및 전송' 서비스(1708)는 CDR 생성, 및 SD-CDF로부터 OMB 백본 과금 서비스의 일부인 SD-CGF로의 CDR 전송을 지원한다. 본질적으로, 서비스 계층 CDR을 생성하는 것은 <eventConfig> 및 <statsCollect>를 따르는 검출된 과금 이벤트를 표현하는 과금 데이터 레코드(CDR)를 저장하는 새로운 <statsRecord> 리소스의 생성을 필요로 한다. 이 서비스는 모든 유형들의 과금 이벤트들에 대해 일반적이다.

이러한 2개의 서비스는 SD-CDF에 의해 생성된 CDR들에 작용하고, 함께 협력하여 SD-CGF를 구현한다.

'CDR 처리' 서비스(1710)는 이하의 동작들을 수행한다:

● 새로운 CDR을 처리하는데, 예를 들어, 파라미터들을 유효성 검사하고, 동일한 애플리케이션 또는 동일한 서비스 제공자에 속하는 CDR들을 집계한다.

● CDR을 기존 CDR 파일에 통합하거나 새로운 CDR을 포함하는 새로운 CDR 파일을 생성한다.

'CDR 파일 전송' 서비스(1712)는 CDR 파일들을 서비스 계층 청구서 작성 도메인(1208)에 전송하고, 전송 오류들이 있다면 그것들을 처리하는 것을 담당한다. SD-CGF와 서비스 청구서 작성 도메인(1208) 사이의 CDR 파일들의 전송에 사용되는 기준점은 Mch로 정의된다. CDR 파일들은 푸시 모드 또는 풀 모드로 전송될 수 있다.

"요금율 구성" 서비스(1714)는 온라인 과금을 위해서만 사용되는 SD-CTF의 부분이다. 요금율 구성은 요구되는 서비스 유닛 및 가격 비용(예를 들어, 트랜잭션 당 5 달러)을 계산하기 위해 유닛/가격 요금율(즉, SD-RF)에 의해 사용될 온라인 과금 이벤트에 관한 요금율 정보를 사전 구성하기 위해 사용된다. 요금율 정보는 서비스 사용 또는 과금 이벤트 트리거에 대한 비용(서비스 유닛 및 가격)을 정의한다.

'온라인 과금 이벤트 식별' 서비스는 요청된 동작들 또는 서비스들에 대응하여 임의의 온라인 과금 이벤트가 트리거되는지 체크하기 위해 사용된다. "온라인 과금 이벤트 식별" 서비스는 온라인 과금만을 위한 것이다.

"요금율 요청" 서비스(1716)는 온라인 과금을 위해서만 사용되는 SD-CTF의 부분이다. 일반적으로, 이 기능부는 SD-CTF가 온라인 과금 이벤트에 대한 요청에 기초한 서비스 전달의 비용을 필요로 할 때 트리거된다. 요금율 요청 기능부는 요구되는 서비스 유닛들은 물론 금전적 비용을 얻기 위한 SD-RF와의 상호작용 및 통신을 담당한다. 요금율 요청은 이하의 사례들에 의해 트리거될 수 있다:

● 온라인 과금 이벤트로서 구성된 동작을 요청하는 요청이 수신된다.

● 요금율 정보가 변경된다.

● 서비스 전달 파라미터(예를 들어, QoS)가 변경된다.

"계정 잔액 및 크레디트 요청" 서비스(1718)는 온라인 과금을 위해서만 사용되는 SD-CTF의 부분이다. 이 기능부는 서비스 사용에 대한 계정 잔액 체크 및/또는 계정 크레디트 업데이트/예약이 필요할 때 SD-ABMF와 통신하기 위해 사용된다.

"서비스 전달 모니터링" 서비스(1720)는 온라인 과금을 위해서만 사용되는 SD-CTF의 부분이다. 이 기능부는 서비스 유닛들이 승인되고 계정 크레디트가 업데이트 또는 예약된 후에 서비스 전달을 모니터링하는 것이다. 이는 모든 승인된 유닛들이 모두 소모되고 클라이언트가 계속하여 서비스를 사용하기를 원하는 것, 또는 승인된 유닛들이 소모되지 않고 서비스 전달이 완료되는 것이 가능하기 때문에 필요하다. 두 경우들 모두에서, 계정 잔액 및 크레디트 요청 기능부를 트리거함으로써 추가 계정 잔액 체크 및 크레디트 업데이트/예약을 위해 SD-ABMF가 접촉될 것이다.

"유닛/가격 요금율" 서비스(1722)는 온라인 과금을 위해서만 SD-RF를 구현한다. 그것은 발원자에 의해 요청되는 동작들 또는 서비스에 대해 요구되는 서비스 유닛 비용 및 금전적 비용을 계산하는 것을 담당한다. 그것은 온라인 과금을 위해서만 사용된다. 이 서비스는 oneM2M 서비스(즉, CSF)뿐만 아니라 특정 표준 기구와 호환될 필요가 없는 임의의 제3자 서비스에도 제공될 수 있도록 OMB 백본 과금 서비스에 상주한다.

"계정 잔액 체크" 서비스(1726) 및 "크레디트 업데이트/예약" 서비스(1724)는 온라인 과금만을 위해 SD-ABMF의 기능성을 구현한다. 2개의 별개의 기능이 존재한다:

● 사용자들/애플리케이션들이 서비스를 사용하기 위한 충분한 크레디트를 갖는지를 결정하기 위해, 계정 잔액/크레디트를 체크한다.

● 계정 잔액/크레디트를 업데이트하고, 서비스 전달에 대해 크레디트를 예약한다.

도 17은 OMB 시스템 내의 서비스 계층 과금 활동의 이하의 배치 시나리오를 보여준다.

● 시나리오 1: 애플리케이션(즉, AE)은 OMB 백본 내의 데이터베이스에서 새로운 과금 이벤트를 구성한다. 새로운 과금 이벤트가 생성되고 구성될 때, IN-CSE 내의 CSF는 데이터베이스 서비스로부터 새로운 과금 이벤트의 구성에 대해 통지받는다. CSF는 자신의 서비스를 이용한 것에 대하여 사용자들/애플리케이션들에 과금하기 위해 새로운 과금 이벤트를 사용하기로 결정하고, 과금 이벤트의 발생을 검출하고 보고한다. 백본 과금 서비스(즉, SD-CDF 및 SD-CGF)는 CDR 생성을 위해 사용된다. 추가로, IN-CSE 내의 CSF는 새로운 과금 이벤트 구성의 로컬 사본(즉, <eventConfig> 및 <statsCollect>)을 임의적으로(optionally) 생성하고 유지할 수 있다. AE는 Mca 기준점을 통해 과금 이벤트를 구성한다.

● 시나리오 2: IN-CSE 내부의 서비스(즉, CSF)는 백본 데이터베이스에서 과금 이벤트 및 통계 수집 정보를 구성하고, 백본 데이터베이스 내의 SD-CTF에 의존하여 CDR 생성을 트리거하기 위한 과금 이벤트의 발생을 검출하고 보고한다. 이 시나리오에서, 과금 이벤트 및 통계 수집 정보는 백본 데이터베이스 내의 리소스 트리(즉, <eventConfig> 및 <statsCollect>)에 유지될 것이다.

● 시나리오 3: 제3자 서비스는 서비스 계층 플랫폼(1102)을 통해 프로비저닝된다. 과금 이벤트는 제3자 서비스에 의해 로컬로 구성되고 유지되며, 서비스 계층에 불투명하다. 이는 임의의 데이터 구조 및 형식이 이 정보를 유지하기 위해 사용될 수 있음을 암시한다. 제3자 서비스는 SD-CTF를 구현하기 위해 자기 자신만의 독점적인 방법을 사용할 수 있음에 유의해야 한다. 제3자 서비스는 CDR 및 CDR 파일 생성을 위해 OMB 백본 내의 SD-CDF 및 SD-CGF를 각각 사용한다.

위의 시나리오들은 오프라인 및 온라인 과금 둘 다에 유효하며, 기저 네트워크 과금 시스템과의 상관을 포함하지 않지만, SCEF는 3GPP 과금 시스템과 연동하는 엔티티로서 보여진다는 점에 유의해야 한다. 상관은 본 개시내용의 범위를 벗어나는 것이기 때문이다.

도 17에 도시된 기능성은 이하에 설명되는 도 22c 또는 도 22d에 도시된 것들과 같은 무선 디바이스, 또는 다른 장치(예를 들어, 서버, 게이트웨이, 디바이스, 또는 다른 컴퓨터 시스템)의 메모리 내에 저장되고 그것들의 프로세서 상에서 실행되는 소프트웨어(즉, 컴퓨터 실행가능한 명령어들)의 형태로 구현될 수 있다. 또한, 도 17에 도시된 기능성은 가상화된 네트워크 기능부들의 세트로서 구현될 수 있음이 이해된다. 네트워크 기능부들은 반드시 직접 통신하지는 않을 수 있으며, 오히려 포워딩 또는 라우팅 기능부를 통해 통신할 수 있다.

또 다른 실시예에서, 도 18은 이하의 단계들로 배치 시나리오 1에 대한 오프라인 과금 절차를 보여준다:

도 18의 단계(1)에서, AE(1802)는 오프라인 과금 이벤트 및 통계 수집 정보를 구성하라는 요청을 OMB 백본에 있는 데이터베이스 서비스(1804)에 송신한다. IN-CSE는 요청을 트랜짓 노드에 포워딩할 것이다.

도 18의 단계(2)에서, 데이터베이스 서비스(1804) 내의 SD-CTF의 부분들은 과금 이벤트 및 통계 수집을 구성한다.

도 18의 단계(3)에서, 데이터베이스 서비스(1804)는 새로운 과금 이벤트 및 통계 수집의 구성에 관한 통지를 IN-CSE 내의 CSF(들)(1806)에 송신한다. 이러한 CSF(들)는 새로운 과금 이벤트 구성의 이벤트에 미리 가입한다고 가정한다.

도 18의 단계(4)에서, 통지된 각각의 CSF(1806)는 새롭게 구성된 과금 이벤트 및 대응하는 통계 수집을 적용하기를 원하는지의 결정을 내릴 것이다. 하나의 CSF가 과금 이벤트를 적용하기로 결정한다고 가정하면, 그것은 과금 이벤트 정보 및 통계 수집 구성을 저장할 로컬 복사본을 임의적으로 생성한다. 과금 이벤트 정보 및 통계 수집 구성은 로컬 데이터베이스(1808)에 저장될 수 있다.

도 18의 단계(5)에서, CSF(1806) 내의 SD-CTF는 임의의 요청된 동작이 구성된 과금 이벤트와 일치하는지를 계속하여 모니터링하고, 그것이 발생할 때 과금 이벤트 정보를 수집한다.

도 18의 단계(6)에서, CSF(1806) 내의 SD-CTF는 과금 이벤트의 발생 및 대응하는 통계 정보에 관하여 백본 과금 서비스(1810) 내의 SD-CDF에 보고한다.

도 18의 단계(7)에서, CDR이 생성되어 CDR 파일들에 추가된다.

도 18에 도시된 단계들을 수행하는 엔티티들은 도 22c 또는 도 22d에 도시된 것들과 같은 컴퓨터 시스템 또는 무선 및/또는 네트워크 통신들을 위해 구성된 장치의 메모리 내에 저장되고 그것들의 프로세서 상에서 실행되는 소프트웨어(즉, 컴퓨터 실행가능한 명령어들)의 형태로 구현될 수 있는 논리적 엔티티들일 수 있다. 즉, 도 18에 도시된 방법(들)은 도 22c 또는 도 22d에 도시된 컴퓨터 시스템 또는 장치와 같은 장치의 메모리에 저장된 소프트웨어(즉, 컴퓨터 실행가능한 명령어들)의 형태로 구현될 수 있고, 그것의 컴퓨터 실행가능한 명령어들은 장치의 프로세서에 의해 실행될 때 도 18에 도시된 단계들을 수행한다. 또한, 도 18에 도시된 기능성은 가상화된 네트워크 기능부들의 세트로서 구현될 수 있음이 이해된다. 네트워크 기능부들은 반드시 직접 통신하지는 않을 수 있으며, 오히려 포워딩 또는 라우팅 기능부를 통해 통신할 수 있다. 또한, 도 18에 도시된 임의의 송신 및 수신 단계들은 장치의 프로세서, 및 그것이 실행하는 컴퓨터 실행가능한 명령어들(예를 들어, 소프트웨어)의 제어 하에서 장치의 통신 회로에 의해 수행될 수 있음이 이해된다.

또 다른 실시예에서, 도 19는 이하의 단계들로 배치 시나리오 1에 대한 온라인 과금 절차를 보여준다:

도 19의 단계들(1 내지 4)에서, 애플리케이션(AE)(1802)은 도 18에 보여진 단계들(1 내지 4)과 동일한 프로세스에 따라 데이터베이스에서 과금 이벤트 및 통계 수집을 구성한다. 예외로, 요금율 정보는 이벤트 정보 및 통계 수집 정보와 함께 구성된다.

도 19의 단계(5)에서, SD-CTF(1902)는 온라인 과금 이벤트로서 구성된 동작을 요청하는 요청을 수신할 때까지 계속하여 요청을 모니터링한다.

도 19의 단계들(6 내지 8)에서, IN-CSE 내의 SD-CTF(1902)는 OMB 백본 과금 서비스에 상주하는 SD-RF(1904)에 접촉하여, 요청된 서비스/동작을 제공하기 위한 요구되는 서비스 유닛들 및 금전적 비용의 양을 계산한다. 이러한 양은 SD-CTF(1902)에 리턴된다.

도 19의 단계들(9 내지 11)에서, SD-CTF(1902)는 계정 잔액 및 관리 기능에 더 접촉하여, 요청자가 자신의 계정 내에 요청된 동작/서비스를 제공하기에 충분한 크레디트를 갖는지를 결정하고, SD-ABMF(1906)에 크레디트를 예약하도록 요청한다.

도 19의 단계(12)에서, SD-CTF(1902)는 동작/서비스가 완료되기 전에 예약된 크레디트들이 다 소비되지 않을 것을 보장하기 위해 승인된 유닛들의 사용을 계속하여 모니터링한다.

도 19의 단계들(13 내지 15)에서, SD-CTF(1902)는 동작이 완료되거나 서비스 전달이 완료된 후에 계정 잔액을 업데이트하도록 SD-ABMF(1906)에 통지한다.

도 19에 도시된 단계들을 수행하는 엔티티들은 도 22c 또는 도 22d에 도시된 것들과 같은 컴퓨터 시스템 또는 무선 및/또는 네트워크 통신들을 위해 구성된 장치의 메모리 내에 저장되고 그것들의 프로세서 상에서 실행되는 소프트웨어(즉, 컴퓨터 실행가능한 명령어들)의 형태로 구현될 수 있는 논리적 엔티티들일 수 있다. 즉, 도 19에 도시된 방법(들)은 도 22c 또는 도 22d에 도시된 컴퓨터 시스템 또는 장치와 같은 장치의 메모리에 저장된 소프트웨어(즉, 컴퓨터 실행가능한 명령어들)의 형태로 구현될 수 있고, 그것의 컴퓨터 실행가능한 명령어들은 장치의 프로세서에 의해 실행될 때 도 19에 도시된 단계들을 수행한다. 또한, 도 19에 도시된 기능성은 가상화된 네트워크 기능부들의 세트로서 구현될 수 있음이 이해된다. 네트워크 기능부들은 반드시 직접 통신하지는 않을 수 있으며, 오히려 포워딩 또는 라우팅 기능부를 통해 통신할 수 있다. 또한, 도 19에 도시된 임의의 송신 및 수신 단계들은 장치의 프로세서, 및 그것이 실행하는 컴퓨터 실행가능한 명령어들(예를 들어, 소프트웨어)의 제어 하에서 장치의 통신 회로에 의해 수행될 수 있음이 이해된다.

시나리오 2 및 3의 오프라인 및 온라인 과금 절차는 시나리오 1의 동작들과 유사하다. 주요 차이점은 과금 이벤트, 통계 수집, 및 요금율 정보를 구성하는 엔티티이다.

SGi 인터페이스는 EPC, 특히 P-GW와 PDN 사이에서 3GPP에 의해 정의된 "기준점"이다. SGi-LAN은 SGi 기준점에서(즉, 2개의 네트워크 사이에서) 모바일 운영자들에 의해 배치된 기능부들을 지칭한다. 전형적인 기능부들은 방화벽, 네트워크 주소 변환, 딥 패킷 검사(Deep Packet Inspection)(DPI) 노드, 비디오 및 TCP 최적화기, 콘텐츠 캐시일 수 있다. SGi-LAN은 논리적으로, 그리고 위상기하학적으로 다수의 병렬 서비스 경로로 조직되며, 각각의 경로는 특정 가입자 서브세트(예를 들어, 기업 고객) 또는 특정 트래픽 유형(예를 들어, 비디오, 웹)에 값을 제공한다.

또 다른 실시예에서, 도 20은 SDN 및 NFV가 통합된 유연한 서비스 계층 과금 기능성/서비스를 갖는 SGi-LAN(2002)의 예시적인 아키텍처를 보여준다.

도 20의 실시예에 예시적으로 도시된 기능성은 이하에 설명되는 도 22c 또는 도 22d에 도시된 것들과 같은 무선 디바이스, 또는 다른 장치(예를 들어, 서버, 게이트웨이, 디바이스, 또는 다른 컴퓨터 시스템)의 메모리 내에 저장되고 그것들의 프로세서 상에서 실행되는 소프트웨어(즉, 컴퓨터 실행가능한 명령어들)의 형태로 구현될 수 있음이 이해된다. 또한, 도 20에 도시된 기능성은 가상화된 네트워크 기능부들의 세트로서 구현될 수 있음이 이해된다. 네트워크 기능부들은 반드시 직접 통신하지는 않을 수 있으며, 오히려 포워딩 또는 라우팅 기능부를 통해 통신할 수 있다.

파라미터들은 이전 섹션들에서 유연한 서비스 계층 과금을 가능하게 하기 위해 정의된다. 과금 이벤트, 통계 수집 및 요금율 정보에 대해 그러한 파라미터들을 구성하거나 프로그래밍하기 위해 사용자 인터페이스가 구현될 수 있다. 예시적인 사용자 인터페이스(2102)가 도 21에 도시되어 있다. 애플리케이션 서비스 제공자, 서비스 제공자, 및/또는 네트워크 운영자는 이 인터페이스를 사용하여 게이트웨이 또는 서버에서 그들의 서비스들에 대한 과금 이벤트 및 요금율 체계를 구성할 수 있다. 인터페이스(2102)는 이하에 설명되는 도 22c-도 22d에 도시된 것과 같은 디스플레이들을 사용하여 생성될 수 있음을 이해해야 한다.

예시적인 M2M / IoT / WoT 통신 시스템

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

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

도 22a는 하나 이상의 개시된 실시예가 구현될 수 있는 예시적인 머신-대-머신(M2M), 사물 인터넷(IoT), 또는 사물 웹(WoT) 통신 시스템(10)의 도면이다. 일반적으로, M2M 기술들은 IoT/WoT를 위한 빌딩 블록들을 제공하고, 임의의 M2M 디바이스, M2M 게이트웨이, M2M 서버, 또는 M2M 서비스 플랫폼은 IoT/WoT의 컴포넌트 또는 노드는 물론, IoT/WoT 서비스 계층 등일 수 있다. 통신 시스템(10)은 개시된 실시예들의 기능성을 구현하기 위해 이용될 수 있고, SD-CTF(1202, 1210, 1212, 1504, 1902), SD-CDF(1204), SD-CGF(1206), CSE들(1224, 1222 및 1220), 서비스 청구서 작성 도메인(1208), SD-RF(1302, 1904), SD-ABMF(1304, 1604, 1906), 애플리케이션들(1104, 1106, 1108, 1402, 1406, 1502, 1802), 서비스 계층 플랫폼(1102), M2M 게이트웨이(1408), M2M 서버(1404), '과금 이벤트 구성' 서비스(1702), '과금 이벤트 검출' 서비스(1704), '과금 이벤트 보고' 서비스(1706), 'CDR 생성 및 전송' 서비스(1708), 'CDR 처리' 서비스(1710), 'CDR 파일 전송' 서비스(1712), "요금율 구성" 서비스(1714), '온라인 과금 이벤트 식별' 서비스, "요금율 요청" 서비스(1716), "계정 잔액 및 크레디트 요청" 서비스, "서비스 전달 모니터링" 서비스(1720), "유닛/가격 요금율" 서비스(1722), "계정 잔액 체크" 서비스(1726), "크레디트 업데이트/예약" 서비스(1724), CSF(1806), 데이터베이스 서비스(1804), 로컬 데이터베이스(1808), 오프라인 과금 서비스(1810), SGi-LAN(2002), 및 GUI(2102)와 같은 인터페이스들을 생성하기 위한 논리적 엔티티들과 같은 기능성 및 논리적 엔티티들을 포함할 수 있다.

도 22a에 도시된 바와 같이, M2M/IoT/WoT 통신 시스템(10)은 통신 네트워크(12)를 포함한다. 통신 네트워크(12)는 고정 네트워크(예를 들어, 이더넷, 광섬유, ISDN, PLC 등), 또는 무선 네트워크(예를 들어, WLAN, 셀룰러 등), 또는 이종 네트워크들의 네트워크일 수 있다. 예를 들어, 통신 네트워크(12)는 음성, 데이터, 비디오, 메시징, 방송 등과 같은 콘텐츠를 다수의 사용자에게 제공하는 복수의 액세스 네트워크로 구성될 수 있다. 예를 들어, 통신 네트워크(12)는 코드 분할 다중 액세스(CDMA), 시분할 다중 액세스(TDMA), 주파수 분할 다중 액세스(FDMA), 직교 FDMA(OFDMA), 싱글 캐리어 FDMA(SC-FDMA) 등과 같은 하나 이상의 채널 액세스 방법을 이용할 수 있다. 또한, 통신 네트워크(12)는 예를 들어 코어 네트워크, 인터넷, 센서 네트워크, 산업 제어 네트워크, 개인 도메인 네트워크, 융합된 개인 네트워크, 위성 네트워크, 홈 네트워크, 또는 기업 네트워크와 같은 다른 네트워크들을 포함할 수 있다.

도 22a에 도시된 바와 같이, 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 단말 디바이스들(18)은 태블릿, 스마트 폰, 의료 디바이스, 온도 및 날씨 모니터, 커넥티드 카, 스마트 미터, 게임 콘솔, 개인용 정보 단말, 헬스 및 피트니스 모니터, 조명, 서모스탯, 가전 제품, 차고 문 및 다른 액추에이터 기반 디바이스, 보안 장치 및 스마트 콘센트를 포함하지만, 그에 한정되지 않는다.

도 22b를 참조하면, 필드 도메인 내의 도시된 M2M 서비스 계층(22)은 M2M 애플리케이션(20), M2M 게이트웨이 디바이스들(14), 및 M2M 단말 디바이스(18), 및 통신 네트워크(12)에 대한 서비스들을 제공한다. 통신 네트워크(12)는 개시된 실시예들의 기능성을 구현하기 위해 이용될 수 있고, SD-CTF(1202, 1210, 1212, 1504, 1902), SD-CDF(1204), SD-CGF(1206), CSE들(1224, 1222 및 1220), 서비스 청구서 작성 도메인(1208), SD-RF(1302, 1904), SD-ABMF(1304, 1604, 1906), 애플리케이션들(1104, 1106, 1108, 1402, 1406, 1502, 1802), 서비스 계층 플랫폼(1102), M2M 게이트웨이(1408), M2M 서버(1404), '과금 이벤트 구성' 서비스(1702), '과금 이벤트 검출' 서비스(1704), '과금 이벤트 보고' 서비스(1706), 'CDR 생성 및 전송' 서비스(1708), 'CDR 처리' 서비스(1710), 'CDR 파일 전송' 서비스(1712), "요금율 구성" 서비스(1714), '온라인 과금 이벤트 식별' 서비스, "요금율 요청" 서비스(1716), "계정 잔액 및 크레디트 요청" 서비스, "서비스 전달 모니터링" 서비스(1720), "유닛/가격 요금율" 서비스(1722), "계정 잔액 체크" 서비스(1726), "크레디트 업데이트/예약" 서비스(1724), CSF(1806), 데이터베이스 서비스(1804), 로컬 데이터베이스(1808), 오프라인 과금 서비스(1810), SGi-LAN(2002), 및 GUI(2102)와 같은 인터페이스들을 생성하기 위한 논리적 엔티티들과 같은 기능성 및 논리적 엔티티들을 포함할 수 있다. M2M 서비스 계층(22)은 예를 들어 이하에 설명되는 도 22c 및 도 22d에 도시된 디바이스들을 포함하는, 하나 이상의 서버, 컴퓨터, 디바이스, 가상 머신들[클라우드/스토리지 팜(storage farms) 등] 등에 의해 구현될 수 있다. 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')은 서버들, 컴퓨터들, 디바이스들, 가상 머신들(예를 들어, 클라우드 컴퓨팅/스토리지 팜 등) 등을 포함할 수 있는 네트워크의 하나 이상의 노드에 의한 것이다.

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

본 출원의 방법들은 서비스 계층(22 및 22')의 일부로서 구현될 수 있다. 서비스 계층(22 및 22')은 애플리케이션 프로그래밍 인터페이스들(Application Programming Interfaces)(API들) 및 기저 네트워킹 인터페이스들의 세트를 통해 부가가치 서비스 능력들을 지원하는 소프트웨어 미들웨어 계층이다. ETSI M2M 및 oneM2M 둘 다는 본 출원의 접속 방법들을 포함할 수 있는 서비스 계층을 사용한다. ETSI M2M의 서비스 계층은 서비스 능력 계층(Service Capability Layer)(SCL)이라고 지칭된다. SCL은 M2M 디바이스[디바이스 SCL(DSCL)이라고 지칭됨], 게이트웨이[게이트웨이 SCL(GSCL)이라고 지칭됨], 및/또는 네트워크 노드[네트워크 SCL(NSCL)이라고 지칭됨] 내에서 구현될 수 있다. oneM2M 서비스 계층은 공통 서비스 기능들(CSF)(즉, 서비스 능력들)의 세트를 지원한다. 하나 이상의 특정 유형의 CSF들의 세트의 인스턴스화는 상이한 유형들의 네트워크 노드들(예를 들어, 기반구조 노드, 중간 노드, 애플리케이션-특정 노드)에서 호스팅될 수 있는 공통 서비스 엔티티(Common Services Entity)(CSE)로 지칭된다. 또한, 본 출원의 접속 방법들은 서비스 지향 아키텍처(Service Oriented Architecture)(SOA) 및/또는 리소스 지향 아키텍처(Resource Oriented Architecture)(ROA)를 사용하여 본 출원의 접속 방법들과 같은 서비스들에 액세스하는 M2M 네트워크의 일부로서 구현될 수 있다.

일부 실시예들에서, M2M 애플리케이션들(20 및 20')은 개시된 시스템들 및 방법들에 관련하여 사용될 수 있다. M2M 애플리케이션들(20 및 20')은 UE 또는 게이트웨이와 상호작용하는 애플리케이션들을 포함할 수 있고, 또한 다른 개시된 시스템들 및 방법들과 관련하여 사용될 수 있다.

일 실시예에서, SD-CTF(1202, 1210, 1212, 1504, 1902), SD-CDF(1204), SD-CGF(1206), CSE들(1224, 1222 및 1220), 서비스 청구서 작성 도메인(1208), SD-RF(1302, 1904), SD-ABMF(1304, 1604, 1906), 애플리케이션들(1104, 1106, 1108, 1402, 1406, 1502, 1802), 서비스 계층 플랫폼(1102), M2M 게이트웨이(1408), M2M 서버(1404), '과금 이벤트 구성' 서비스(1702), '과금 이벤트 검출' 서비스(1704), '과금 이벤트 보고' 서비스(1706), 'CDR 생성 및 전송' 서비스(1708), 'CDR 처리' 서비스(1710), 'CDR 파일 전송' 서비스(1712), "요금율 구성" 서비스(1714), '온라인 과금 이벤트 식별' 서비스, "요금율 요청" 서비스(1716), "계정 잔액 및 크레디트 요청" 서비스, "서비스 전달 모니터링" 서비스(1720), "유닛/가격 요금율" 서비스(1722), "계정 잔액 체크" 서비스(1726), "크레디트 업데이트/예약" 서비스(1724), CSF(1806), 데이터베이스 서비스(1804), 로컬 데이터베이스(1808), 오프라인 과금 서비스(1810), SGi-LAN(2002), 및 GUI(2102)와 같은 인터페이스들을 생성하기 위한 논리적 엔티티들과 같은 논리적 엔티티들은 도 22b에 보여진 바와 같이 M2M 서버, M2M 게이트웨이, 또는 M2M 디바이스와 같은 M2M 노드에 의해 호스팅되는 M2M 서비스 계층 인스턴스 내에서 호스팅될 수 있다. 예를 들어, SD-CTF(1202, 1210, 1212, 1504, 1902), SD-CDF(1204), SD-CGF(1206), CSE들(1224, 1222 및 1220), 서비스 청구서 작성 도메인(1208), SD-RF(1302, 1904), SD-ABMF(1304, 1604, 1906), 애플리케이션들(1104, 1106, 1108, 1402, 1406, 1502, 1802), 서비스 계층 플랫폼(1102), M2M 게이트웨이(1408), M2M 서버(1404), '과금 이벤트 구성' 서비스(1702), '과금 이벤트 검출' 서비스(1704), '과금 이벤트 보고' 서비스(1706), 'CDR 생성 및 전송' 서비스(1708), 'CDR 처리' 서비스(1710), 'CDR 파일 전송' 서비스(1712), "요금율 구성" 서비스(1714), '온라인 과금 이벤트 식별' 서비스, "요금율 요청" 서비스(1716), "계정 잔액 및 크레디트 요청" 서비스, "서비스 전달 모니터링" 서비스(1720), "유닛/가격 요금율" 서비스(1722), "계정 잔액 체크" 서비스(1726), "크레디트 업데이트/예약" 서비스(1724), CSF(1806), 데이터베이스 서비스(1804), 로컬 데이터베이스(1808), 오프라인 과금 서비스(1810), SGi-LAN(2002), 및 GUI(2102)와 같은 인터페이스들을 생성하기 위한 논리적 엔티티들과 같은 논리적 엔티티들은 M2M 서비스 계층 인스턴스 내에서, 또는 기존 서비스 능력 내의 하위 기능으로서 개별 서비스 능력을 포함할 수 있다.

M2M 애플리케이션들(20 및 20')은 운송, 헬스 및 웰니스, 커넥티드 홈, 에너지 관리, 자산 추적, 및 보안 및 감시와 같은, 그러나, 그에 한정되지는 않는 다양한 산업 분야의 애플리케이션들을 포함할 수 있다. 위에서 언급된 바와 같이, 시스템의 디바이스들, 게이트웨이들, 서버들, 및 다른 노드들에 걸쳐 운영되는 M2M 서비스 계층은, 예를 들어 데이터 수집, 디바이스 관리, 보안, 과금, 위치 추적/지오펜싱(geofencing), 디바이스/서비스 발견, 및 레거시 시스템 통합과 같은 기능들을 지원하고, 이러한 기능들을 M2M 애플리케이션들(20 및 20')에 대한 서비스들로서 제공한다.

일반적으로, 서비스 계층들(22 및 22')은 애플리케이션 프로그래밍 인터페이스들(API) 및 기저 네트워킹 인터페이스들의 세트를 통해 부가가치 서비스 능력들을 지원하는 소프트웨어 미들웨어 계층을 정의한다. ETSI M2M 및 oneM2M 아키텍처 둘 다는 서비스 계층을 정의한다. ETSI M2M의 서비스 계층은 서비스 능력 계층(SCL)이라고 지칭된다. SCL은 ETSI M2M 아키텍처의 다양한 상이한 노드들에서 구현될 수 있다. 예를 들어, 서비스 계층의 인스턴스는 M2M 디바이스[디바이스 SCL(DSCL)이라고 지칭됨], 게이트웨이[게이트웨이 SCL(GSCL)이라고 지칭됨], 및/또는 네트워크 노드[네트워크 SCL(NSCL)이라고 지칭됨] 내에서 구현될 수 있다. oneM2M 서비스 계층은 공통 서비스 기능들(CSF)(즉, 서비스 능력들)의 세트를 지원한다. 하나 이상의 특정 유형의 CSF들의 세트의 인스턴스화는 상이한 유형들의 네트워크 노드들(예를 들어, 기반구조 노드, 중간 노드, 애플리케이션-특정 노드)에서 호스팅될 수 있는 공통 서비스 엔티티(CSE)로 지칭된다. 3세대 파트너쉽 프로젝트(3GPP)는 또한 머신 유형 통신(MTC)을 위한 아키텍처를 정의했다. 그러한 아키텍처에서, 서비스 계층, 및 그것이 제공하는 서비스 능력들은 서비스 능력 서버(SCS)의 일부로서 구현된다. ETSI M2M 아키텍처의 DSCL, GSCL 또는 NSCL에서 구현되는지, 3GPP MTC 아키텍처의 서비스 능력 서버(SCS)에서 구현되는지, oneM2M 아키텍처의 CSF 또는 CSE에서 구현되는지, 또는 네트워크의 소정의 다른 노드에서 구현되는지에 무관하게, 서비스 계층의 인스턴스는 서버들, 컴퓨터들, 및 다른 컴퓨팅 디바이스들 또는 노드들을 포함하는 네트워크 내의 하나 이상의 독립형 노드 상에서, 또는 하나 이상의 기존 노드의 일부로서 실행되는 논리적 엔티티(예를 들어, 소프트웨어, 컴퓨터 실행가능한 명령어들 등)로서 구현될 수 있다. 예로서, 서비스 계층 또는 그 컴포넌트의 인스턴스는 이하에 설명되는 도 22c 또는 도 22d에 도시된 일반적인 아키텍처를 갖는 네트워크 노드(예를 들어, 서버, 컴퓨터, 게이트웨이, 디바이스 등)에서 실행되는 소프트웨어의 형태로 구현될 수 있다.

또한, SD-CTF(1202, 1210, 1212, 1504, 1902), SD-CDF(1204), SD-CGF(1206), CSE들(1224, 1222 및 1220), 서비스 청구서 작성 도메인(1208), SD-RF(1302, 1904), SD-ABMF(1304, 1604, 1906), 애플리케이션들(1104, 1106, 1108, 1402, 1406, 1502, 1802), 서비스 계층 플랫폼(1102), M2M 게이트웨이(1408), M2M 서버(1404), '과금 이벤트 구성' 서비스(1702), '과금 이벤트 검출' 서비스(1704), '과금 이벤트 보고' 서비스(1706), 'CDR 생성 및 전송' 서비스(1708), 'CDR 처리' 서비스(1710), 'CDR 파일 전송' 서비스(1712), "요금율 구성" 서비스(1714), '온라인 과금 이벤트 식별' 서비스, "요금율 요청" 서비스(1716), "계정 잔액 및 크레디트 요청" 서비스, "서비스 전달 모니터링" 서비스(1720), "유닛/가격 요금율" 서비스(1722), "계정 잔액 체크" 서비스(1726), "크레디트 업데이트/예약" 서비스(1724), CSF(1806), 데이터베이스 서비스(1804), 로컬 데이터베이스(1808), 오프라인 과금 서비스(1810), SGi-LAN(2002), 및 GUI(2102)와 같은 인터페이스들을 생성하기 위한 논리적 엔티티들과 같은 논리적 엔티티들은 본 출원의 서비스들에 액세스하기 위해 서비스 지향 아키텍처(SOA) 및/또는 리소스 지향 아키텍처(ROA)를 사용하는 M2M 네트워크의 일부로서 구현될 수 있다.

도 22c는 M2M 디바이스(18), M2M 게이트웨이(14), M2M 서버 등과 같은 M2M 네트워크 노드(30)의 예시적인 하드웨어/소프트웨어 아키텍처의 블록도이다. 노드(30)는 SD-CTF(1202, 1210, 1212, 1504, 1902), SD-CDF(1204), SD-CGF(1206), CSE들(1224, 1222 및 1220), 서비스 청구서 작성 도메인(1208), SD-RF(1302, 1904), SD-ABMF(1304, 1604, 1906), 애플리케이션들(1104, 1106, 1108, 1402, 1406, 1502, 1802), 서비스 계층 플랫폼(1102), M2M 게이트웨이(1408), M2M 서버(1404), '과금 이벤트 구성' 서비스(1702), '과금 이벤트 검출' 서비스(1704), '과금 이벤트 보고' 서비스(1706), 'CDR 생성 및 전송' 서비스(1708), 'CDR 처리' 서비스(1710), 'CDR 파일 전송' 서비스(1712), "요금율 구성" 서비스(1714), '온라인 과금 이벤트 식별' 서비스, "요금율 요청" 서비스(1716), "계정 잔액 및 크레디트 요청" 서비스, "서비스 전달 모니터링" 서비스(1720), "유닛/가격 요금율" 서비스(1722), "계정 잔액 체크" 서비스(1726), "크레디트 업데이트/예약" 서비스(1724), CSF(1806), 데이터베이스 서비스(1804), 로컬 데이터베이스(1808), 오프라인 과금 서비스(1810), SGi-LAN(2002), 및 GUI(2102)와 같은 인터페이스들을 생성하기 위한 논리적 엔티티들과 같은 논리적 엔티티들을 실행하거나 포함할 수 있다. 디바이스(30)는 도 22a 내지 도 22b에 보여진 것과 같은 M2M 네트워크의 일부, 또는 비-M2M 네트워크의 일부일 수 있다. 도 22c에 보여진 바와 같이, M2M 노드(30)는 프로세서(32), 고정식 메모리(44), 이동식 메모리(46), 스피커/마이크로폰(38), 키패드(40), 디스플레이, 터치패드, 및/또는 표시기들(42), 전원(48), 전지구적 측위 시스템(global positioning system)(GPS) 칩셋(50), 및 다른 주변장치들(52)을 포함할 수 있다. 노드(30)는 또한 송수신기(34) 및 송신/수신 요소(36)와 같은 통신 회로를 포함할 수 있다. M2M 노드(30)는 실시예와의 일관성을 유지하면서, 상술한 요소들의 임의의 서브컴비네이션(sub-combination)을 포함할 수 있음을 알 것이다. 이 노드는 본 명세서에 설명된 SMSF 기능을 구현하는 노드일 수 있다.

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

도 22c에 도시된 바와 같이, 프로세서(32)는 자신의 통신 회로[예컨대, 송수신기(34) 및 송신/수신 요소(36)]에 연결된다. 프로세서(32)는 컴퓨터 실행가능한 명령어들의 실행을 통해, 노드(30)가 자신이 접속된 네트워크를 통해 다른 노드들과 통신하게 하기 위해 통신 회로를 제어할 수 있다. 구체적으로, 프로세서(32)는 본 명세서 및 청구항들에 설명된 송신 및 수신 단계들을 수행하기 위해 통신 회로를 제어할 수 있다. 도 22c는 프로세서(32) 및 송수신기(34)를 별개의 컴포넌트들로서 도시하지만, 프로세서(32) 및 송수신기(34)는 전자 패키지 또는 칩 내에 함께 통합될 수 있음을 알 것이다.

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

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

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

프로세서(32)는 고정식 메모리(44) 및/또는 이동식 메모리(46)와 같은 임의의 유형의 적절한 메모리로부터 정보에 액세스하고 그러한 메모리에 데이터를 저장할 수 있다. 예를 들어, 프로세서(32)는 위에서 설명된 바와 같이 세션 컨텍스트를 그것의 메모리 내에 저장할 수 있다. 고정식 메모리(44)는 랜덤 액세스 메모리(random-access memory)(RAM), 판독 전용 메모리(read-only memory)(ROM), 하드 디스크, 또는 임의의 다른 유형의 메모리 저장 디바이스를 포함할 수 있다. 이동식 메모리(46)는 가입자 신원 모듈(SIM) 카드, 메모리 스틱, 보안 디지털(SD) 메모리 카드 등을 포함할 수 있다. 다른 실시예들에서, 프로세서(32)는 서버 또는 홈 컴퓨터와 같이 M2M 노드(30) 상에 물리적으로 위치하지 않는 메모리로부터 정보에 액세스하고 그러한 메모리에 데이터를 저장할 수 있다. 프로세서(32)는 M2M 서비스 계층 세션 마이그레이션 또는 공유의 상태를 반영하기 위해, 또는 노드의 세션 마이그레이션 또는 공유 능력들 또는 세팅들에 관하여 사용자로부터 입력을 획득하거나 사용자에게 정보를 디스플레이하기 위해, 디스플레이 상의 조명 패턴들, 이미지들, 또는 컬러들, 또는 표시기들(42)을 제어하도록 구성될 수 있다. 다른 예에서, 디스플레이는 세션 상태에 관련된 정보를 보여줄 수 있다. 본 개시내용은 oneM2M 실시예에서 RESTful 사용자/애플리케이션 API를 정의한다. 디스플레이 상에 보여질 수 있는 그래픽 사용자 인터페이스는 사용자가 본 명세서에 설명된 기저 서비스 계층 세션 기능성을 통해 E2E 세션, 또는 그것의 마이그레이션 또는 공유를 상호작용 방식으로 확립하고 관리하는 것을 허용하기 위해 API의 최상부에 계층화될 수 있다.

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

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

프로세서(32)는 추가 특징들, 기능성, 및/또는 유선 또는 무선 접속성을 제공하는 하나 이상의 소프트웨어 및/또는 하드웨어 모듈을 포함할 수 있는 다른 주변장치들(52)에 더 연결될 수 있다. 예를 들어, 주변장치들(52)은 가속도계, 생체 인식(예를 들어, 지문) 센서, 전자 나침반, 위성 송수신기, 디지털 카메라(사진 또는 비디오를 위한 것), 범용 직렬 버스(USB) 포트 또는 다른 상호접속 인터페이스들, 진동 디바이스, 텔레비젼 송수신기, 핸즈프리 헤드셋, 블루투스(Bluetooth®) 모듈, 주파수 변조(FM) 무선 유닛, 디지털 뮤직 플레이어, 미디어 플레이어, 비디오 게임 플레이어 모듈, 인터넷 브라우저 등과 같은 다양한 센서들을 포함할 수 있다.

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

도 22d는 M2M 서버, 게이트웨이, 디바이스 또는 다른 노드와 같은 M2M 네트워크의 하나 이상의 노드를 구현하는 데에도 사용될 수 있는 예시적인 컴퓨팅 시스템(90)의 블록도이다. 컴퓨팅 시스템(90)은 컴퓨터 또는 서버를 포함할 수 있고, 소프트웨어가 저장 또는 액세스되는 모든 장소에서, 또는 소프트웨어가 저장 또는 액세스되는 모든 수단에 의해, 그러한 소프트웨어 형태로 되어 있을 수 있는 컴퓨터 판독가능한 명령어들에 의해 주로 제어될 수 있다. 컴퓨팅 시스템(90)은 SD-CTF(1202, 1210, 1212, 1504, 1902), SD-CDF(1204), SD-CGF(1206), CSE들(1224, 1222 및 1220), 서비스 청구서 작성 도메인(1208), SD-RF(1302, 1904), SD-ABMF(1304, 1604, 1906), 애플리케이션들(1104, 1106, 1108, 1402, 1406, 1502, 1802), 서비스 계층 플랫폼(1102), M2M 게이트웨이(1408), M2M 서버(1404), '과금 이벤트 구성' 서비스(1702), '과금 이벤트 검출' 서비스(1704), '과금 이벤트 보고' 서비스(1706), 'CDR 생성 및 전송' 서비스(1708), 'CDR 처리' 서비스(1710), 'CDR 파일 전송' 서비스(1712), "요금율 구성" 서비스(1714), '온라인 과금 이벤트 식별' 서비스, "요금율 요청" 서비스(1716), "계정 잔액 및 크레디트 요청" 서비스, "서비스 전달 모니터링" 서비스(1720), "유닛/가격 요금율" 서비스(1722), "계정 잔액 체크" 서비스(1726), "크레디트 업데이트/예약" 서비스(1724), CSF(1806), 데이터베이스 서비스(1804), 로컬 데이터베이스(1808), 오프라인 과금 서비스(1810), SGi-LAN(2002), 및 GUI(2102)와 같은 인터페이스들을 생성하기 위한 논리적 엔티티들과 같은 논리적 엔티티들을 실행하거나 포함할 수 있다. 컴퓨팅 시스템(90)은 예를 들어 M2M 디바이스, 사용자 장비, 게이트웨이, UE/GW 또는 모바일 케어 네트워크의 임의의 다른 노드들, 서비스 계층 네트워크 애플리케이션 제공자, 단말 디바이스(18) 또는 M2M 게이트웨이 디바이스(14)일 수 있다. 그러한 컴퓨터 판독가능한 명령어들은 컴퓨팅 시스템(90)이 작업을 수행하도록 하기 위해, 중앙 처리 장치(CPU)(91)와 같은 프로세서 내에서 실행될 수 있다. 다수의 공지된 워크스테이션, 서버, 및 개인용 컴퓨터에서, 중앙 처리 장치(91)는 마이크로프로세서라고 지칭되는 단일 칩 CPU에 의해 구현된다. 다른 머신들에서, 중앙 처리 유닛(91)은 다수의 프로세서를 포함할 수 있다. 코프로세서(81)는 추가의 기능들을 수행하거나 CPU(91)를 보조하는, 메인 CPU(91)와 구별되는 임의적 프로세서이다. CPU(91) 및/또는 코프로세서(81)는 세션 자격증명들을 수신하는 것, 또는 세션 자격증명들에 기초하여 인증하는 것과 같은 E2E M2M 서비스 계층 세션들에 대해 개시된 시스템들 및 방법들에 관련된 데이터를 수신하고 발생하고 처리할 수 있다.

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

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

추가로, 컴퓨팅 시스템(90)은 CPU(91)로부터 프린터(94), 키보드(84), 마우스(95), 및 디스크 드라이브(85)와 같은 주변장치들에 명령어들을 전달하는 것을 책임지는 주변장치 제어기(83)를 포함할 수 있다.

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

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

사용자 장비(UE)는 통신을 위해 최종 사용자에 의해 사용되는 임의의 디바이스일 수 있다. 그것은 핸드헬드 전화기, 모바일 광대역 어댑터가 장착된 랩탑 컴퓨터, 또는 임의의 다른 디바이스일 수 있다. 예를 들어, UE는 도 22a 내지 도 22b의 M2M 단말 디바이스(18) 또는 도 22c의 디바이스(30)로서 구현될 수 있다.

본 명세서에 설명된 시스템들, 방법들, 및 프로세스들 중 임의의 것 또는 전부는 컴퓨터 판독가능한 저장 매체 상에 저장된 컴퓨터 실행가능한 명령어들(즉, 프로그램 코드)의 형태로 구현될 수 있으며, 그러한 명령어들은 예를 들어 M2M 서버, 게이트웨이, 디바이스 등을 포함하는 M2M 네트워크의 노드와 같은 머신에 의해 실행될 때, 본 명세서에 설명된 시스템들, 방법들, 및 프로세스들을 수행 및/또는 구현한다는 것이 이해된다. 구체적으로, 게이트웨이, UE, UE/GW, 또는 모바일 코어 네트워크, 서비스 계층 또는 네트워크 애플리케이션 제공자의 노드들 중 임의의 것의 동작들을 포함하여 위에서 설명된 단계들, 동작들 또는 기능들 중 임의의 것은 그러한 컴퓨터 실행가능한 명령어들의 형태로 구현될 수 있다. SD-CTF(1202, 1210, 1212, 1504, 1902), SD-CDF(1204), SD-CGF(1206), CSE들(1224, 1222 및 1220), 서비스 청구서 작성 도메인(1208), SD-RF(1302, 1904), SD-ABMF(1304, 1604, 1906), 애플리케이션들(1104, 1106, 1108, 1402, 1406, 1502, 1802), 서비스 계층 플랫폼(1102), M2M 게이트웨이(1408), M2M 서버(1404), '과금 이벤트 구성' 서비스(1702), '과금 이벤트 검출' 서비스(1704), '과금 이벤트 보고' 서비스(1706), 'CDR 생성 및 전송' 서비스(1708), 'CDR 처리' 서비스(1710), 'CDR 파일 전송' 서비스(1712), "요금율 구성" 서비스(1714), '온라인 과금 이벤트 식별' 서비스, "요금율 요청" 서비스(1716), "계정 잔액 및 크레디트 요청" 서비스, "서비스 전달 모니터링" 서비스(1720), "유닛/가격 요금율" 서비스(1722), "계정 잔액 체크" 서비스(1726), "크레디트 업데이트/예약" 서비스(1724), CSF(1806), 데이터베이스 서비스(1804), 로컬 데이터베이스(1808), 오프라인 과금 서비스(1810), SGi-LAN(2002), 및 GUI(2102)와 같은 인터페이스들을 생성하기 위한 논리적 엔티티들은 컴퓨터 판독가능한 저장 매체 상에 저장된 컴퓨터 실행가능한 명령어들의 형태로 구현될 수 있다. 컴퓨터 판독가능한 저장 매체는 정보의 저장을 위해 임의의 비-일시적(즉, 실체있는 또는 물리적) 방법 또는 기술로 구현된 휘발성 및 비휘발성의 이동식 및 고정식 매체 모두를 포함하지만, 이러한 컴퓨터 판독가능한 저장 매체는 신호들을 포함하지 않는다. 컴퓨터 판독가능한 저장 매체는 RAM, ROM, EEPROM, 플래시 메모리, 또는 다른 메모리 기술, CD-ROM, DVD(digital versatile disk) 또는 다른 광학 디스크 저장소, 자기 카세트들, 자기 테이프, 자기 디스크 저장소 디바이스, 또는 다른 자기 저장소, 또는 원하는 정보를 저장하는 데 사용될 수 있고 컴퓨터에 의해 액세스될 수 있는 임의의 다른 실체있는 또는 물리적 매체를 포함하지만 그에 한정되지 않는다.

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

이러한 서술된 설명은 예들을 사용하여 최선의 모드를 포함하는 본 발명을 개시하고, 또한 본 기술분야의 통상의 기술자가 임의의 디바이스들 또는 시스템들을 제작 및 사용하고 임의의 통합된 방법들을 수행하는 것을 포함하여 본 발명을 실시할 수 있게 한다. 본 발명의 특허가능한 범위는 청구항들에 의해 정의되며, 본 기술분야의 통상의 기술자에게 떠오를 수 있는 다른 예들을 포함할 수 있다. 그러한 다른 예들은 그것들이 청구항들의 문자 언어와 다른 요소들을 갖는 경우 또는 청구항들의 문자 언어와 사소한 차이를 갖는 등가의 요소들을 포함하는 경우, 청구항들의 범위 내에 있는 것으로 의도된다.

Claims (20)

1. 네트워크 상의 장치로서,
   이벤트의 온라인 과금을 위한 명령어들이 저장된 비-일시적 메모리; 및
   상기 비-일시적 메모리에 동작가능하게 결합된 프로세서
   를 포함하고, 상기 프로세서는:
   M2M 게이트웨이로부터, 서비스 계층 온라인 과금(service layer online charging)을 위한 요금율 요청 메시지(rating request message)를 수신하고;
   상기 이벤트에 대해 과금하기 위한 요금율 체계(rating scheme)를 결정하고;
   상기 요금율 요청 메시지 및 결정된 요금율 체계에 기초하여 요구되는 서비스 유닛들의 양을 계산하고;
   상기 M2M 게이트웨이에, 서비스 유닛들의 계산된 양에 기초하여 요금율 응답을 송신하는
   명령어들을 실행하도록 구성되는 장치.
2. 제1항에 있어서, 상기 프로세서는:
   상기 요구되는 서비스 유닛들, 상기 요금율 요청 메시지, 및 결정된 요금율 체계에 기초하여 금전적 비용을 계산하고;
   상기 요금율 응답을 상기 계산된 금전적 비용과 함께 상기 M2M 게이트웨이에 송신하는
   명령어들을 실행하도록 추가로 구성되는 장치.
3. 제1항에 있어서, 상기 요금율 요청 메시지는 온라인 과금 이벤트 이름, 온라인 과금 ID, 애플리케이션 ID, 요청된 동작, 요청된 서비스, 상기 요청된 동작의 수량, 상기 요청된 서비스의 수량, 및 이들의 조합들로부터 선택된 세부사항들을 포함하는 장치.
4. 제1항에 있어서,
   상기 비-일시적 메모리 및 프로세서에 동작가능하게 결합되는 요금율 기능부를 더 포함하고, 상기 요금율 기능부는 서비스 유닛들 및 금전적 비용의 나타내어지는 양을 계산하기 위해, 과금 이벤트 정보, 애플리케이션 식별, 및 요청된 동작으로부터의 정보를 사용하도록 구성되는 장치.
5. 제4항에 있어서, 상기 M2M 게이트웨이로부터 계정 크레디트 체크 메시지를 수신하도록 구성되는 계정 잔액 및 관리 기능부를 더 포함하며, 상기 계정 잔액 및 관리 기능부는 상기 요금율 기능부와 통신하는 장치.
6. 제5항에 있어서, 상기 계정 크레디트 체크 메시지는 상기 요금율 기능부에 의해 사용되는 서비스 유닛들의 요구되는 양, 상기 요금율 기능부에 의한 요구되는 계산된 비용, 애플리케이션 ID, 애플리케이션 외부 ID, 서비스 제공자 ID, 서비스 계층 플랫폼 운영자 ID, 및 이들의 조합들로부터 선택된 정보를 포함하는 장치.
7. 제5항에 있어서, 상기 계정 잔액 및 관리 기능부는:
   상기 게이트웨이로부터, 서비스 전달을 시작하기 전에 크레디트를 예약하라는 크레디트 예약 요청을 수신하고;
   상기 서비스 전달에 대한 크레디트를 예약하는
   명령어들을 실행하도록 구성되는 장치.
8. 제7항에 있어서, 상기 계정 잔액 및 관리 기능부는:
   상기 게이트웨이로부터, 승인된 서비스 유닛들의 고갈에 기초하여 상기 결정 및 상기 계산을 반복하라는 요청을 수신하는 명령어들을 실행하도록 구성되는 장치.
9. 제1항에 있어서, 상기 프로세서는:
   애플리케이션으로부터, 상기 이벤트에 대해 과금하기 위해 사용되는 상기 요금율 체계를 구성하라는 요금율 구성 요청을 수신하는 명령어들을 실행하도록 추가로 구성되는 장치.
10. 제9항에 있어서, 상기 요금율 구성 요청은 온라인 과금 이벤트에 대한 참조, 요금율 체계가 적용되는 애플리케이션들의 목록, 온라인 과금 시나리오, 서비스 유닛 측정, 서비스 유닛 당 비용, 및 이들의 조합들로부터 선택되는 파라미터들을 포함하는 장치.
11. 제9항에 있어서, 상기 이벤트에 대해 과금하기 위한 상기 요금율 체계는 하나 이상의 애플리케이션 사이에서 달라지는 장치.
12. 네트워크 상에서 동작하는 장치로서,
    요금율 정보를 구성하기 위한 명령어들이 저장된 비-일시적 메모리; 및
    상기 비-일시적 메모리에 동작가능하게 결합된 프로세서
    를 포함하고, 상기 프로세서는:
    발원자로부터, 요금율 정보를 포함하는 요금율 구성 요청 메시지를 수신하고;
    상기 발원자로부터 수신된 상기 요금율 정보를 M2M 서버에 저장하고;
    상기 M2M 서버 내의 서비스 도메인 과금 트리거 기능부에서 상기 요금율 정보를 구성하고;
    상기 M2M 서버로부터, 상기 구성된 요금율 정보를 포함하는 응답을 상기 발원자에게 송신하는
    명령어들을 실행하도록 구성되는 장치.
13. 제12항에 있어서, 상기 요금율 정보는 온라인 과금 이벤트에 대한 참조, 요금율 체계를 적용할 애플리케이션들의 목록, 온라인 과금 시나리오, 서비스 유닛 측정, 서비스 유닛 당 비용, 및 이들의 조합들로부터 선택되는 장치.
14. 제12항에 있어서, 상기 요금율 정보는 정의된 온라인 과금 이벤트를 위해 이용되는 장치.
15. 제12항에 있어서, 상기 요금율 구성 요청은 과금 이벤트 유형 속성 및 이벤트 기준 속성을 포함하는 장치.
16. 제12항에 있어서, 상기 요금율 구성 요청은 온라인 과금 이벤트에 연관된 리소스 유형 속성 및 애플리케이션 유형 속성을 포함하는 장치.
17. 제12항에 있어서, 상기 요금율 구성 요청은 캡처된 이벤트의 위치 및 영역을 제공하는 locationRestriction 속성을 포함하는 장치.
18. 네트워크에서의 이벤트의 온라인 과금 방법으로서,
    M2M 서버에서, 서비스 계층 온라인 과금을 위한 요금율 요청 메시지를 수신하는 단계;
    상기 M2M 서버 내의 서비스 도메인 요금율 기능부에서, 상기 이벤트에 대해 과금하기 위한 요금율 체계를 결정하는 단계; 및
    상기 M2M 서버 내의 상기 서비스 도메인 요금율 기능부에서, 상기 요금율 요청 메시지 및 결정된 요금율 체계에 기초하여 서비스 유닛들의 양을 계산하는 단계
    를 포함하는 방법.
19. 제18항에 있어서,
    상기 M2M 게이트웨이에, 상기 서비스 유닛들의 계산된 양에 기초하여 요금율 응답을 송신하는 단계를 더 포함하는 방법.
20. 제18항에 있어서,
    상기 요금율 요청 메시지 및 결정된 요금율 체계에 따라 금전적 비용을 계산하는 단계를 더 포함하는 방법.

Images