KR20190129934A - 네트워크 서비스 계층에서의 분산형 트랜잭션 관리 - Google Patents

네트워크 서비스 계층에서의 분산형 트랜잭션 관리 Download PDF

Info

Publication number
KR20190129934A
KR20190129934A KR1020197030278A KR20197030278A KR20190129934A KR 20190129934 A KR20190129934 A KR 20190129934A KR 1020197030278 A KR1020197030278 A KR 1020197030278A KR 20197030278 A KR20197030278 A KR 20197030278A KR 20190129934 A KR20190129934 A KR 20190129934A
Authority
KR
South Korea
Prior art keywords
dslt
service layer
transaction
request
resource
Prior art date
Application number
KR1020197030278A
Other languages
English (en)
Other versions
KR102436426B1 (ko
Inventor
데일 엔. 시드
줘 천
쇼사나 레브
취앙 리
카탈리나 엠. 믈라딘
윌리엄 로버트 4세 플린
로코 디지로라모
Original Assignee
콘비다 와이어리스, 엘엘씨
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 콘비다 와이어리스, 엘엘씨 filed Critical 콘비다 와이어리스, 엘엘씨
Publication of KR20190129934A publication Critical patent/KR20190129934A/ko
Application granted granted Critical
Publication of KR102436426B1 publication Critical patent/KR102436426B1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G06F16/2379—Updates performed during online database operations; commit processing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/466—Transaction processing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/52—Program synchronisation; Mutual exclusion, e.g. by means of semaphores
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H04L67/32—
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Computing Systems (AREA)
  • Health & Medical Sciences (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Computer And Data Communications (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

분산형 서비스 계층 트랜잭션(DSLT)들은, DSLT들의 처리를 관리하는 부담으로부터 애플리케이션들을 오프로드하기 위해 통신 네트워크의 서비스 계층에서 DSLT 서비스에 의해 지원될 수 있다.

Description

네트워크 서비스 계층에서의 분산형 트랜잭션 관리
관련 출원들에 대한 상호-참조
본 출원은 "Methods to Enable Distributed Transaction Management at the IoT Service Layer"라는 명칭으로 2017년 3월 17일자로 출원된 미국 가특허 출원 제62/472,851호의 이익을 주장하며, 상기 가출원의 내용은 그 전체가 인용에 의해 본원에 포함된다.
트랜잭션은 유닛으로서 수행될 필요가 있는 동작들의 세트 또는 동작들의 시퀀스일 수 있다. 동작들의 세트는 (예컨대, 기능상의 또는 사업상의 이유들로) 밀접하게 관련될 수 있으며, 유닛으로서, 이들 전부가 성공적으로 실행되거나 이들 중 어느 것도 실행되지 않을 필요가 있다. 트랜잭션은 원자성, 일관성, 격리성, 및 내구성(ACID; Atomicity, Consistency, Isolation and Durability)의 4가지 특성을 가질 수 있다. 원자성은, 트랜잭션이 얼마나 많은 요청들 또는 단계들을 갖는지에 상관없이, 트랜잭션이 하나의 단일 요청인 것처럼 그 요청들 또는 단계들이 실행되어야 함을 의미한다. 그 요청들 또는 단계들은 모두가 성공적으로 실행되거나 전혀 실행되지 않아야 한다. 부분적 실행은 허용되지 않는다. 일관성은, 트랜잭션의 표적들의 상태가 트랜잭션의 실행 이전과 이후에 일관되어야 함을 의미한다. 일관성은 원자성과 밀접하게 관련된다. 격리성은, 트랜잭션들이 서로에 대해 격리될 필요가 있고 트랜잭션들이 서로에 대해 간섭할 수 없음을 의미한다. 내구성은, 일단 트랜잭션이 커밋되면, 시스템은 트랜잭션의 결과가 안전하고 내구성이 있다는 것을 보장할 필요가 있음을 의미한다. 결과는 갑작스러운 오작동을 견딜 수 있고, 복원 후에 그 결과로 복원될 수 있다. 최근에, 머신-투-머신(M2M; machine-to-machine) 또는 사물 인터넷(IoT; Internet of things) 네트워크들의 맥락에서 트랜잭션 처리를 해결하기 위한 노력들이 이루어졌다.
통신 네트워크의 서비스 계층에서 분산형 트랜잭션 처리에 대한 지원을 제공하기 위한 방법들, 장치, 및 시스템이 본원에 개시된다. 방법들, 장치, 및 시스템들은, 분산형 서비스 계층 트랜잭션(DSLT)들의 처리를 스스로 관리해야 하는 복잡성 및 부담으로부터 애플리케이션들을 오프로드하기 위한, DSLT 처리 능력들을 지원하는 DSLT 서비스로 구현될 수 있다. DSLT 처리 능력들은, DSLT의 원자적 처리를 애플리케이션들을 대신하여 관리하는 DSLT 서비스의 능력; DSLT들의 시퀀스의 원자적 처리를 애플리케이션들을 대신하여 관리하는 DSLT 서비스의 능력; DSLT 또는 DSLT들의 시퀀스를 구성하는 개별 요청들의 스케줄링을 조정하는 DSLT 서비스의 능력; 애플리케이션들이 DSLT 또는 DSLT들의 시퀀스의 실행 기준들을 정의할 수 있게 하는 DSLT 서비스의 능력; 애플리케이션들이 DSLT 또는 DSLT들의 시퀀스의 재송신 정책들을 정의할 수 있게 하는 DSLT 서비스의 능력; 애플리케이션들이 DSLT 또는 DSLT들의 시퀀스의 완료 기준을 정의할 수 있게 하는 DSLT 서비스의 능력; 애플리케이션들이 DSLT 또는 DSLT들의 시퀀스의 우선순위를 정의할 수 있게 하는 DSLT 서비스의 능력; 및 DSLT 또는 DSLT들의 시퀀스를 개시하기 위해 간단한 레스트풀(RESTful) API를 애플리케이션들에 제공하는 DSLT 서비스의 능력을 포함할 수 있다.
일 양상에서, DSLT 서비스를 구현하는, 통신 네트워크 상의 제1 서비스 계층 엔티티는, 통신 네트워크 상에서 실행되는 애플리케이션으로부터 분산형 트랜잭션에 대한 요청을 수신할 수 있다. 요청은, 통신 네트워크의 다수의 다른 서비스 계층 엔티티들에 의해 호스팅되는 표적화된 리소스들의 세트 상에서 원자적으로 실행될 명령을 특정할 수 있다. 요청에 대한 응답으로, 제1 서비스 계층 엔티티는, 다수의 다른 서비스 계층 엔티티들 각각에, 그 다른 서비스 계층 엔티티에 의해 호스팅되는 임의의 표적화된 리소스들을 잠그기 위한 요청을 전송할 수 있다. 이어서, 제1 서비스 계층 엔티티는, 다수의 다른 서비스 계층 엔티티들 각각으로부터, 그 서비스 계층 엔티티가 그 서비스 계층 엔티티에 의해 호스팅되는 표적화된 리소스들을 잠글 수 있었는지 여부를 표시하는 응답을 수신할 수 있다. 제1 서비스 계층 엔티티가 표적화된 리소스들 전부가 잠겼음을 표시하는 응답들을 수신하는 경우, 제1 서비스 계층 엔티티는, 표적화된 리소스들의 세트 상에서 명령의 원자적 실행을 수행하기 위한 요청들을 다수의 다른 서비스 계층 엔티티들에 전송할 수 있다. 표적화된 리소스들의 세트 상에서 명령이 성공적으로 실행되었다는 것을 표시하는 응답들을 제1 서비스 계층 엔티티가 수신하는 경우, 제1 서비스 계층 엔티티는, 분산형 트랜잭션을 커밋하기 위한 요청들을 다수의 다른 서비스 계층 엔티티들에 전송할 수 있다. 이어서, 제1 서비스 계층 엔티티는, 분산형 트랜잭션이 성공적으로 수행되었음을 표시하는 응답을 애플리케이션에 전송할 수 있다.
추가적인 양상에 따르면, 제1 서비스 계층 엔티티는, 애플리케이션으로부터 분산형 트랜잭션에 대한 요청을 수신할 시, 분산형 트랜잭션을 표현하고 분산형 트랜잭션의 상태에 관한 정보를 포함하는 리소스를 제1 서비스 계층 엔티티의 메모리에 생성할 수 있다. 리소스는, 애플리케이션이 트랜잭션의 상태를 모니터링할 수 있게 하기 위해, 통신 네트워크를 통해 애플리케이션이 액세스가능하게 될 수 있다. 리소스는, 트랜잭션을 고유하게 식별하는 트랜잭션 식별자 속성 및 분산형 트랜잭션의 상태에 관한 정보가 저장되는 트랜잭션 상태 속성을 포함할 수 있다. 리소스는, 제1 서비스 계층 엔티티가 분산형 트랜잭션에 대한 요청의 처리를 개시할 때를 제어하는 실행 시간 속성을 더 포함할 수 있다.
본 개요는, 상세한 설명에서 아래에 추가로 설명되는 개념들의 선택을 간략화된 형태로 소개하기 위해 제공된다. 본 개요는, 청구된 주제의 핵심적인 특징들 또는 필수적인 특징들을 식별하도록 의도되지 않고, 청구된 주제의 범위를 제한하는 것으로 사용되도록 의도되지도 않는다. 또한, 청구된 주제는 본 개시내용의 임의의 부분에서 언급되는 임의의 또는 모든 단점들을 해결하는 제한들로 제한되지 않는다.
첨부한 도면들과 함께 예로서 주어지는 다음의 설명으로부터 더 상세한 이해가 이루어질 수 있다.
도 1은, 서비스 계층을 지원하는 예시적인 프로토콜 스택을 예시하는 도면이다.
도 2는, 다양한 유형들의 네트워크 노드들 상에 배치되는 M2M/IoT 서비스 계층(SL)을 예시하는 도면이다.
도 3은, 원엠투엠(oneM2M) 아키텍처를 예시하는 도면이다.
도 4는, 원엠투엠 공통 서비스 기능들을 예시하는 도면이다.
도 5는, 원엠투엠 아키텍처에 의해 지원되는 구성들을 예시하는 도면이다.
도 6은, 원엠투엠 <transaction> 리소스를 예시하는 도면이다.
도 7은, 원엠투엠 트랜잭션 처리(성공적인 경우)를 예시하는 도면이다.
도 8은, 원엠투엠 트랜잭션 처리(실패한 경우)를 예시하는 도면이다.
도 9는, SL 트랜잭션 관리의 유용성을 입증하는 스마트 공장 사용 경우를 예시하는 도면이다.
도 10은, 분산형 서비스 계층 트랜잭션(DSLT)을 위한 최소 SL 해결책을 예시하는 도면이다.
도 11은, DSLT를 위한 완전한 SL 해결책을 예시하는 도면이다.
도 12는, DSLT 배치 옵션들을 예시하는 도면이다.
도 13은, 분산형 서비스 계층 트랜잭션 관리 기능(DSLT-MF)을 예시하는 도면이다.
도 14는, 분산형 서비스 계층 트랜잭션 클라이언트 기능(DSLT-CF)을 예시하는 도면이다.
도 15는, 개별 DSLT에 대한 DSLT-TF 처리를 예시하는 도면이다.
도 16은, 개별 DSLT에 대한 DSLT-MF 처리를 예시하는 도면이다.
도 17은, 개별 DSLT-CF에 대한 DSLT-CF 처리를 예시하는 도면이다.
도 18은, DSLT 시퀀스에 대한 DSLT-TF 처리를 예시하는 도면이다.
도 19는, DSLT 시퀀스에 대한 DSLT-MF 처리를 예시하는 도면이다.
도 20은, DSLT 시퀀스에 대한 DSLT-CF 처리를 예시하는 도면이다.
도 21은, 개별 DSLT 절차를 예시하는 도면이다.
도 22는, DSLT 시퀀싱 절차를 예시하는 도면이다.
도 23은, 원엠투엠에서의 트랜잭션 관리 CSF의 아키텍처 실시예를 예시하는 도면이다.
도 24는, 원엠투엠 리소스들에 대한 DSLT 지향 속성들을 예시하는 도면이다.
도 25는, 원엠투엠 DSLT 시퀀스 리소스를 예시하는 도면이다.
도 26은, 원엠투엠 <group> 리소스에 대한 DSLT 향상들을 예시하는 도면이다.
도 27은, 원엠투엠 DSLT 그룹 팬아웃 절차를 예시하는 도면이다.
도 28은, 원엠투엠 DSLT 시퀀싱 절차를 예시하는 도면이다.
도 29는, 서비스 계층 트랜잭션 사용자 인터페이스들을 예시하는 도면이다.
도 30a는, 통신 네트워크를 포함하는 M2M/IoT/WoT 통신 시스템의 도면이다.
도 30b는, M2M 애플리케이션, M2M 게이트웨이 디바이스들, 및 M2M 단말 디바이스들과 통신 네트워크에 대한 서비스들을 제공하는 필드 도메인에서의 예시된 M2M 서비스 계층의 도면이다.
도 30c는, 본원에서 설명된 논리 엔티티들 중 임의의 것을 구현하는 데 사용될 수 있는 예시적인 장치의 도면이다.
도 30d는, 본원에서 설명된 논리 엔티티들 중 임의의 것을 구현하는 데 사용될 수 있는 컴퓨터 시스템 또는 서버의 블록도이다.
다음은, 다음의 설명에서 나타날 수 있는 두문자어들의 목록이다. 달리 특정되지 않는 한, 본원에서 사용된 두문자어들은 아래에 열거된 대응하는 용어를 지칭한다:
ADN 애플리케이션 전용 노드
AE 애플리케이션 엔티티
API 애플리케이션 프로그래밍 인터페이스들
ASN 애플리케이션 서비스 노드
CSE 공통 서비스 엔티티
CSF 공통 서비스 기능
DSLT 분산형 서비스 계층 트랜잭션
DSLT-CF 분산형 서비스 계층 트랜잭션 클라이언트 기능
DSLT-MF 분산형 서비스 계층 트랜잭션 관리 기능
DSLT-TF 분산형 서비스 계층 트랜잭션 촉발 기능
DSLT-REQ 분산형 서비스 계층 트랜잭션 요청
DSLT-TRIGGER 분산형 서비스 계층 트랜잭션 촉발 요청
IN 기반구조 네트워크
IoT 사물 인터넷
IP 인터넷 프로토콜
M2M 머신-투-머신
MN 중간 노드
NoDN 비-원엠투엠 노드
PoA 액세스 포인트
ROA 리소스 지향 아키텍처
SL 서비스 계층
URI 통합 리소스 식별자
또한, 다음의 용어들이 아래의 설명에서 사용될 수 있으며, 달리 특정되지 않는 한, 이러한 용어들은 다음의 의미들을 가질 수 있다:
M2M/IoT 서비스 계층은, 애플리케이션 프로그래밍 인터페이스(API)들과 기본 네트워킹 인터페이스들의 세트를 통해 M2M/IoT 애플리케이션들 및 디바이스들에 대한 부가 가치 서비스들을 지원하는 소프트웨어 미들웨어 계층일 수 있다.
M2M/IoT 애플리케이션은, 특정 M2M/IoT 사용 경우(예컨대, 전자보건(eHealth), 스마트 에너지, 홈 자동화)를 표적화하는 애플리케이션일 수 있다.
서비스 계층 엔티티는, M2M/IoT 애플리케이션, 또는 M2M/IoT 서비스 계층의 인스턴스일 수 있다.
서비스 계층 리소스는, M2M/IoT 서비스 계층에 의해 호스팅되는 고유하게 주소지정가능한 객체일 수 있다.
서비스 계층 요청은, 서비스 계층 리소스를 표적화하는 서비스 계층 엔티티에 의해 송출되는 동작일 수 있다.
서비스 계층 트랜잭션은, 전부가 성공적으로 실행되거나 어느 것도 실행되지 않도록 유닛으로서 원자적으로 수행될 필요가 있는 서비스 계층 요청들의 세트 또는 시퀀스일 수 있다.
분산형 서비스 계층 트랜잭션은, 상이한 네트워크 노드들 상에서 호스팅되는 다수의 서비스 계층 엔티티들에 의해 호스팅되는 리소스들의 세트를 표적화하는 서비스 계층 트랜잭션일 수 있다.
분산형 서비스 계층 트랜잭션 관리 기능은, 분산형 서비스 계층 트랜잭션 클라이언트 기능들과 상호작용하여 이러한 기능들에 대한 분산형 서비스 계층 트랜잭션들의 원자적 처리를 관리할 수 있는 서비스 계층 기능일 수 있다.
분산형 서비스 계층 트랜잭션 클라이언트 기능은, 분산형 서비스 계층 트랜잭션 관리 기능들과 상호작용하여 개별 분산형 서비스 계층 트랜잭션들을 수신하여 처리할 수 있는 서비스 계층 기능일 수 있다.
분산형 서비스 계층 트랜잭션 촉발 기능은, 분산형 서비스 계층 트랜잭션 관리 기능들과 상호작용하여 분산형 서비스 계층 트랜잭션들을 개시할 수 있는 서비스 계층 기능일 수 있다.
분산형 서비스 계층 트랜잭션 촉발 요청은, 분산형 서비스 계층 트랜잭션을 개시하기 위해 분산형 서비스 계층 트랜잭션 촉발 기능에 의해 분산형 서비스 계층 트랜잭션 관리 기능에 전송되는 요청일 수 있다.
분산형 서비스 계층 트랜잭션 요청은, 분산형 서비스 계층 트랜잭션을 수행하기 위해 분산형 서비스 계층 트랜잭션 관리 기능에 의해 분산형 서비스 계층 트랜잭션 클라이언트 기능에 배포되는 요청일 수 있다.
머신-투-머신(M2M) 또는 사물 인터넷(IoT) 네트워크에서, 서비스 계층(SL)은, M2M/IoT 디바이스들 및 애플리케이션들에 대한 부가 가치 서비스들을 제공하는 것에 대하여 구체적으로 표적화되는 기술이다. 최근에, 몇몇 산업 표준 기구들(예컨대, 원엠투엠(문헌 [oneM2M TS-0001 원엠투엠 기능 아키텍처-V-3.0.0]), ETSI(문헌 [ETSI TS 102 690 머신-투-머신 통신(M2M) 기능 아키텍처 V2.0.13.]), OCF(문헌 [OCF - OIC 규격, V1.1]) 및 LWM2M(문헌 [OMA LWM2M 규격 V1.0]))은 M2M/IoT 디바이스들 및 애플리케이션들을 인터넷/웹, 셀룰러, 기업, 및 홈 네트워크와의 배치들로 통합하는 것과 연관된 난제들을 해결하기 위한 M2M/IoT SL들을 개발하고 있다.
M2M/IoT 서비스 계층은, 애플리케이션들 및 디바이스들에 M2M/IoT 지향 능력들의 집합에 대한 액세스를 제공할 수 있다. 몇몇 예들은, 보안, 과금, 데이터 관리, 디바이스 관리, 발견, 프로비저닝, 및 연결성 관리를 포함한다. 이러한 능력들은, M2M/IoT SL에 의해 지원되는 메시지 포맷들, 리소스 구조들, 및 리소스 표현들을 이용하는 애플리케이션 프로그래밍 인터페이스(API)들을 통해 애플리케이션들에 이용가능하게 된다.
프로토콜 스택 관점에서, SL들은 전형적으로 애플리케이션 프로토콜 계층 위에 위치되고, 부가 가치 서비스들을 그들이 지원하는 애플리케이션들에 제공한다. 그러므로, SL들은 종종 '미들웨어' 서비스들로서 분류된다. 도 1은, 애플리케이션 프로토콜들(104)과 애플리케이션들(106) 사이의 예시적인 서비스 계층(102)을 도시한다.
배치 관점에서, M2M/IoT SL(102)은, 도 2에 도시된 바와 같이, 서버들, 게이트웨이들, 및 디바이스들을 포함하는 다양한 유형들의 네트워크 노드들 상에 배치될 수 있다. 서비스 계층 기능성을 구현하거나 다른 방식으로 서비스 계층의 인스턴스를 통합하는 통신 네트워크의 임의의 그러한 노드, 서버, 게이트웨이, 디바이스, 장치, 또는 다른 논리 엔티티는 본원에서 서비스 계층 엔티티로 지칭될 수 있다.
원엠투엠 표준(문헌 [oneM2M TS-0001])은 M2M/IoT SL을 정의하며, 그것의 목적은, 전자보건, 차량군 관리(fleet management), 및 스마트 홈들과 같은 상이한 "수직" M2M 시스템들 및 애플리케이션들에 의해 활용될 수 있는 "수평" 서비스들을 제공하는 것이다. 원엠투엠 SL의 아키텍처는, 도 3에 도시된 바와 같이, 서비스 계층을 구현하고 4개의 기준점을 지원하는 공통 서비스 엔티티(CSE)(302)를 정의한다. Mca 기준점은 애플리케이션 엔티티(AE)(304)와 인터페이싱한다. Mcc 기준점은 동일한 서비스 제공자 도메인 내의 다른 CSE(306)와 인터페싱하고, Mcc' 기준점은 상이한 서비스 제공자 도메인에서 다른 CSE와 인터페이싱한다. Mcn 기준점은 기본 네트워크 서비스 엔티티(NSE)와 인터페이싱한다. NSE(308)는 CSE들에 디바이스 관리, 위치 서비스들, 및 디바이스 촉발과 같은 기본 네트워크 서비스들을 제공한다. CSE는, 함께 서비스 계층의 기능성을 형성하는 "발견", "데이터 관리 & 저장소"와 같은 "공통 서비스 기능(CSF)들"로 지칭되는 다수의 논리 기능들을 포함한다. 도 4는 원엠투엠에 의해 지원되는 CSF들을 예시한다. 통신 네트워크의 노드, 서버, 게이트웨이, 디바이스, 장치, 또는 다른 논리 엔티티 상에서 호스팅되는 CSE의 각각의 인스턴스는 본원에서 네트워크의 서비스 계층 엔티티로 지칭될 수 있다.
원엠투엠 아키텍처는 분산형 아키텍처이고, 다음의 유형들의 노드들에 걸쳐 분산형 방식으로 M2M/IoT 서비스들을 배치하는 것을 지원한다:
● 애플리케이션 서비스 노드(ASN): ASN은, 하나의 CSE를 포함하고 적어도 하나의 애플리케이션 엔티티(AE)를 포함하는 노드이다. 예컨대, ASN은 M2M 디바이스에 상주할 수 있다.
● 애플리케이션 전용 노드(ADN): ADN은, 적어도 하나의 AE를 포함하고 CSE를 포함하지 않는 노드이다. 예컨대, 애플리케이션 전용 노드는 제한된 M2M 디바이스에 상주할 수 있다.
● 중간 노드(MN): MN은, 하나의 CSE를 포함하고 0개 이상의 AE를 포함하는 노드이다. 예컨대, MN은 M2M 게이트웨이에 상주할 수 있다.
● 기반구조 노드(IN): IN은, 하나의 CSE를 포함하고 0개 이상의 AE를 포함하는 노드이다. IN에서의 CSE는 다른 노드 유형들에 적용가능하지 않은 CSE 기능들을 포함할 수 있다. 예컨대, IN은 M2M 서비스 기반구조에 상주할 수 있다.
● 비-원엠투엠 노드(NoDN): 비-원엠투엠 노드는, 원엠투엠 엔티티들을 포함하지 않는(AE들 또는 CSE들 중 어느 것도 포함하지 않음) 노드이다. 그러한 노드들은, 관리를 포함하여 상호연동 목적들을 위해 원엠투엠 시스템에 부착되는 디바이스들을 표현한다.
원엠투엠 시스템 내에서 지원되는 다양한 엔티티들을 상호연결하는 가능한 구성들이 도 5에 예시된다.
최근에, 원엠투엠은 SL 트랜잭션들에 대한 지원을 정의하는 것에 대해 작업하기 시작했다. 이러한 작업은, 문헌(oneM2M TR-0020, 서비스 트랜잭션들 및 재사용가능 서비스 계층 컨텍스트 연구, V0.6.0)에서 문서화되어 있다. 오늘에 이르기까지, 지금까지는 하나의 해결책이 정의되었다. 다음은 이러한 해결책의 요약이다.
<transaction> 리소스는 임의의 다른 리소스의 자식일 수 있다. 이는, 부모 리소스가 트랜잭션의 표적이라는 것을 표시한다. <transaction> 리소스의 상태에 기반하여, 원엠투엠 프리미티브(primitive)가 표적 리소스 상에서 실행된다. <transaction> 리소스의 구조가 도 6에 도시되며, 그 속성의 설명이 표 1에 제공된다.
Figure pct00001
도 7 및 도 8은 원엠투엠 시스템에서 <transaction> 리소스를 사용하여 트랜잭션이 처리되는 방식의 흐름들을 도시한다. 도 7은 성공적인 경우에서의 원엠투엠 트랜잭션 처리를 도시한다. 도 8은 실패한 경우에서의 원엠투엠 트랜잭션 처리를 도시한다. 이러한 처리는 하나의 AE 및 다수의 CSE들을 수반한다. AE는, 다수의 CSE들에 걸쳐 트랜잭션의 조정을 개시하고 관리하는 것을 담당한다. 단계들 각각의 상세한 설명들이 아래에서 포착된다.
도 7 및 도 8의 단계(1)에서, AE(702)는 다수의 CSE들 상에 <transaction> 리소스를 생성한다. <transaction>은 각각의 표적화된 리소스의 자식 리소스로서 생성된다. <transaction> 리소스는 트랜잭션뿐만 아니라 실행될 프리미티브의 실행 시간을 포함한다. 상이한 CSE들의 실행 시간은 트랜잭션의 커밋이 조정됨을 보장하기 위해 동일하다. 프리미티브는 또한 실행될 프리미티브의 발신자의 아이덴티티, 동작, 및 내용을 포함한다.
도 7 및 도 8의 단계(2)에서는, <transaction> 생성 요청을 수신한 각각의 CSE(704, 706, 및 708)에서, CSE(704, 706, 및 708)는 <transaction>이 성공적으로 실행될 수 있는지를 확인한다. 확인은, 액세스 권한 확인들, 프리미티브의 포맷이 올바른지를 확인하는 것, 및 실행이 특정 시간에 수행될 수 있는지를 확인하는 것을 포함할 수 있다.
도 7의 단계(3)(성공)에서, 확인이 성공적인 경우, CSE(704, 706, 및 708)는, <transaction> 리소스가 생성되었고 <transaction> 리소스의 부모 리소스가 예비 상태에 들어갔다는 것을 AE(702)에 응답한다. 예비 상태에서, 리소스는, 특정된 실행 시간에 프리미티브의 성공적인 실행의 효과를 잠재적으로 파괴할 임의의 다른 요청을 거절할 것이다.
도 7의 단계(4)(성공)에서, 특정된 실행 시간에, 각각의 CSE(704, 706, 및 708)가 대응하는 프리미티브를 실행할 것이다.
도 8의 단계(3)(실패)에서, 임의의 CSE(이러한 예에서, CSE(708))에 대한 확인이 실패한 경우, 그 CSE(708)는 실패 응답으로 AE에 응답한다. 임의의 실패 응답들을 수신할 시, AE(702)는, 트랜잭션이 모든 CSE들에 걸쳐 원자적으로 수행될 수는 없다고 결정한다. 따라서, AE(702)는, <transaction> 리소스를 성공적으로 생성한 각각의 CSE(이러한 예에서, CSE들(704 및 706))에, 스케줄링된 실행 시간 전에 그것을 삭제하기 위해 삭제 요청을 전송한다. 이는 트랜잭션을 취소한다.
도 8의 단계(4)(실패)에서, <transaction>을 성공적으로 생성한 CSE(이러한 예에서, CSE들(704 및 706))는 트랜잭션을 삭제한다.
다음의 사용 경우는 M2M/IoT 네트워크에서의 트랜잭션 처리 능력들에 대한 필요성을 이해하는 데 도움이 된다. 다수의 로봇들(904, 906, 및 908)을 갖는 도 9의 제조 조립 라인(902)과 같은 스마트 공장 사용 경우를 고려한다. 이러한 로봇들(904, 906, 및 908)은, 조립 라인에 의해 생산되는 제품을 적절하게 조립하기 위해 서로 엄격하게 동기화된 채로 유지되어야 한다. 로봇의 설정들 중 하나가 수정된 경우, 이는 전형적으로, 로봇들이 서로 조화를 이뤄 동작하도록 유지되는 것을 보장하기 위해, 동일한 조립 라인 상에서 동작하는 다른 로봇들에 대해 대응하는 수정들이 이루어질 것을 요구한다. 공장 내의 모든 조립 라인들은 공장의 제어실에 위치된 대응하는 원격 관리 스테이션들로부터 엔지니어들에 의해 모니터링 및 제어된다. 이러한 스테이션들로부터, 각각의 개개의 조립 라인에 대한 로봇들이 엔지니어들에 의해 원격으로 모니터링될 뿐만 아니라 제어될 수 있다. 이는, 로봇들에 대한 유지보수를 수행하기 위해 조립 라인을 셧다운하는 데 있어 비용이 매우 많이 들기 때문에, 공장은 정지 시간을 최소화하고 심지어 조립 라인이 계속 가동 중인 동안 유지보수를 수행하기 위한 방식들을 모색하고 있다. 이를 행하기 위해, 엔지니어들은 엄격하게 조정된 방식으로 로봇들의 설정들을 수정하는 능력을 원할 것이다. 엔지니어들은 또한, 조립 라인 로봇들이 더 이상 특정된 정상상태 범위 내에서 동작하지 않음을 검출하는 것에 기반하여 이러한 업데이트들을 촉발하는 능력을 원할 것이다. 이것이 발생할 때, 엔지니어들은, 상황이 더 나빠지기 전에 그 상황을 정정하기 위해 로봇들(904, 906, 및 908)의 설정들의 구성에 대한 업데이트들을 촉발할 것을 원할 것이다. 이는, 촉발 경우에 기반하여 로봇 설정들을 수정하기 위해 분산형 트랜잭션을 전송하는 능력을 요구한다. 이는 또한, 이러한 트랜잭션이, 로봇들이 조화를 이뤄 동작하도록 유지되고 조립 라인이 정지될 필요 없이 계속 기능하도록 원자적 방식으로 다수의 로봇들(904, 906, 및 908)에 대한 설정들을 업데이트할 것을 요구한다. 그렇게 함으로써, 엔지니어들은, 로봇들(904, 906, 및 908)의 설정들에 대한 변경들이, 모든 로봇들이 자신의 설정들을 성공적으로 변경할 수 있는 경우에만 발생하는 것을 보증할 수 있다. 하나 이상의 로봇이 자신의 설정들을 성공적으로 변경할 수 없는 경우, 로봇 설정들 중 어느 것도 변경되지 않는다. 이는, 로봇들이 더 이상 조화를 이뤄 동작하지 않는 상태에 조립 라인이 처하게 되는 것을 방지하는 것을 돕는다. 로봇들에 대한 이러한 원자적 트랜잭션들의 관리를 조정하기 위해 복잡한 애플리케이션들을 개발해야 하기 보다는, 엔지니어들은, IoT 서비스 플랫폼의 트랜잭션 관리 능력들에 이러한 복잡성을 오프로드하기를 원할 것이다.
오늘에 이르기까지, 리소스들의 분산된 세트를 표적화하는 원자적 트랜잭션들을 수행하는 복잡성 및 부담은 이러한 트랜잭션들을 개시하는 애플리케이션과 이러한 애플리케이션들을 구축 및 배치하는 개발자들에게 직접적으로 책임 지워졌다. 방대한 수의 분산형 디바이스들로 이루어지는 최근 IoT 네트워크 배치들의 크기 및 복잡성이 증가함에 따라, 이러한 애플리케이션들 및 개발자들이 견뎌야 할 이러한 부담이 훨씬 더 커지고 있다. 결과적으로, 원엠투엠과 같은 IoT/M2M 서비스 계층 기술들은 최근에, 분산형 트랜잭션들의 관리에 대해 애플리케이션들을 보조할 필요성을 인식하였다.
지금까지, 분산형 서비스 계층 트랜잭션(DSLT)들의 관리에 대한 매우 기본적이고 최소의 SL 중심적 해결책들만이 정의되었다. 예컨대, 원엠투엠(문헌 [oneM2M TR-0020])에서 정의된 현재의 해결책은 여전히 DSLT를 관리하는 데 있어 애플리케이션들에 과중하게 의존한다. 애플리케이션은, DSLT를 구성하는 개별 요청들 각각을 개시하고 이러한 요청들을 개별 표적화된 리소스들에 전송하는 것을 여전히 담당한다. 애플리케이션은 또한, 이러한 개별 요청들 각각의 진행을 모니터링하여 이들 중 임의의 요청이 실패를 초래하는지 여부 및 DSLT가 전체적으로 중단될 필요가 있는지 여부를 결정하는 것을 여전히 담당한다. DSLT가 중단될 필요가 있는 경우, 애플리케이션은, 표적들 중 어느 표적에 취소 요청을 전송할 필요가 있는지를 계속 추적하는 것을 담당한다. 애플리케이션은 또한, DSLT의 실행 시간을 계속 추적하고, 이러한 타이머가 만료되기 전에 이러한 취소 요청들을 전송하여 DSLT를 구성하는 개별 요청들 모두가 실행 시간이 경과하기 전에 취소됨을 보장하는 것을 담당한다. 따라서, 도 10에 도시된 바와 같이 DSLT들을 관리함에 있어 애플리케이션에 대한 상당한 오버헤드 및 부담이 여전히 존재한다.
도 10의 단계(1)에서, 애플리케이션(1002)은 다수의 디바이스들(1004, 1006, 및 1008)에 트랜잭션 요청을 전송한다.
도 10의 단계(2)에서, 디바이스들(1004, 1006, 및 1008)은, 그들이 트랜잭션을 성공적으로 실행할 수 있는지를 확인한다.
도 10의 단계(3)에서, 디바이스들(1004, 1006, 및 1008)은, 애플리케이션(1002)에 응답하여 그들이 트랜잭션을 실행할 수 있는지를 표시한다. 이러한 예에서, 디바이스(1008)는 트랜잭션을 실행할 수 없다.
도 10의 단계(4)에서, 디바이스들 중 하나(디바이스(1008))가 트랜잭션을 실행할 수 없으므로, 다른 디바이스들(디바이스들(1004 및 1006))에서 트랜잭션이 중단된다.
분산형 서비스 계층 트랜잭션(DSLT)들의 처리를 스스로 관리해야 하는 복잡성 및 부담으로부터 애플리케이션들을 오프로드하기 위한, DSLT 처리 능력들을 지원하는 DSLT 서비스가 본원에서 설명된다. DSLT 처리 능력들은, DSLT의 원자적 처리를 애플리케이션들을 대신하여 관리하는 DSLT 서비스에 대한 능력; DSLT들의 시퀀스의 원자적 처리를 애플리케이션들을 대신하여 관리하는 DSLT 서비스에 대한 능력; DSLT 또는 DSLT들의 시퀀스를 구성하는 개별 요청들의 스케줄링을 조정하는 DSLT 서비스에 대한 능력; 애플리케이션들이 DSLT 또는 DSLT들의 시퀀스에 대한 실행 기준들을 정의할 수 있게 하는 DSLT 서비스에 대한 능력; 애플리케이션들이 DSLT 또는 DSLT들의 시퀀스에 대한 재송신 정책들을 정의할 수 있게 하는 DSLT 서비스에 대한 능력; 애플리케이션들이 DSLT 또는 DSLT들의 시퀀스에 대한 완료 기준을 정의할 수 있게 하는 DSLT 서비스에 대한 능력; 애플리케이션들이 DSLT 또는 DSLT들의 시퀀스에 대한 우선순위를 정의할 수 있게 하는 DSLT 서비스에 대한 능력; 및 DSLT 또는 DSLT들의 시퀀스를 개시하기 위해 간단한 레스트풀 API를 애플리케이션들에 제공하는 DSLT 서비스에 대한 능력을 포함할 수 있다.
DSLT의 원자적 처리를 애플리케이션들을 대신하여 관리하는 DSLT 서비스에 대한 능력에 관하여, 서비스는 그 자체로 분산될 수 있고, 상이한 네트워크 노드들 상에서 호스팅되는 다수의 서비스 계층 엔티티들에 걸쳐 배치될 수 있는 DSLT 관리 기능들 및 DSLT 클라이언트 기능들로 이루어질 수 있다. 애플리케이션은 단지, DSLT를 개시하기 위해 단일 요청을 서비스에 전송하고 DSLT의 처리가 완료될 때 서비스로부터 다시 응답을 수신할 필요만이 있다. 서비스는 애플리케이션이 개별 DSLT 표적들 중 임의의 표적과 통신하거나 그의 라이프사이클에 걸쳐 DSLT를 관리할 것을 요구하지 않을 수 있다. 서비스는, 처리 상태를 제공하고 실패들의 경우에서 DSLT의 롤백을 가능하게 하는 데 사용될 수 있는, DSLT의 처리 동안의 DSLT 상태를 유지할 수 있다. 서비스는, DSLT와 연관된 개별 요청들의 분산된 세트의 성공적인 배포 및 실행을, 임의의 실패들의 경우에서 서비스가 개별 요청들의 롤백 및 중단을 수행할 수 있도록 관리할 수 있으며, 따라서, DSLT의 원자성 요건들이 충족될 수 있다.
DSLT들의 시퀀스의 원자적 처리를 애플리케이션들을 대신하여 관리하는 DSLT 서비스의 능력에 관하여, DSLT들의 시퀀스는, 애플리케이션들을 대신하여 원자적 방식으로 서비스에 의해 순서화 및 수행될 수 있는 DSLT들의 세트로 이루어질 수 있다. 서비스는, DSLT들의 시퀀스의 성공적인 실행을, 임의의 실패들의 경우에서 서비스가 시퀀스의 롤백 및 중단을 수행할 수 있도록 관리할 수 있으며, 따라서, 시퀀스의 원자성 요건들이 충족될 수 있다.
구성가능한 DSLT 정책 엔진을 지원하는 DSLT 서비스의 능력에 관하여, 정책 엔진은 DSLT 정책들의 프로그래밍가능한 세트에 의해 구성될 수 있다. 정책 엔진은, 스케줄링 정책들, 재시도 정책들, 우선순위화 정책들, 실행 기준 정책들, 완료 기준 정책들, 및 시퀀싱 정책들과 같은 DSLT 정책들을 지원할 수 있다. DSLT 정책들은, 서비스가 DSLT들을 처리하는 방식을 제어하는 규칙들을 정의할 수 있다.
DSLT 또는 DSLT들의 시퀀스를 구성하는 개별 요청들의 스케줄링을, 그 요청들이 애플리케이션의 요건들을 충족하고 DSLT 표적들의 요건들(예컨대, 간헐적 네트워크 연결성만을 갖는 IoT 디바이스들)을 또한 충족하는 시간 윈도우에서 수행되도록 조정하는 DSLT 서비스의 능력에 관하여, 서비스는, DSLT들의 표적들인 IoT 디바이스들의 도달가능성 스케줄들을, DSLT가 자신의 표적화된 디바이스들 전부에 대해 성공적으로 수행될 수 있고 DSLT의 원자적 실행 요건들을 충족할 수 있게, 모든 요구되는 디바이스들이 온라인이고 이용가능함을 보장하는 것을 돕도록 조정할 수 있다. 서비스는, 동일한 리소스(들)를 표적화하는 다수의 DSLT들 또는 DSLT 시퀀스들이, 이들 각각이 자신의 대응하는 트랜잭션들이 격리되어 수행되고 간섭받지 않음을 보장하기 위해서는 자신의 표적 리소스(들)에 대한 잠금을 획득해야 하므로, 동시에 실행되지 않음을 보장할 수 있다.
애플리케이션들이 DSLT 또는 DSLT들의 시퀀스에 대한 실행 기준들을 정의할 수 있게 하는 DSLT 서비스의 능력에 관하여, 다음과 같다. 실행 기준들은 DSLT(들)의 실행이 발생하는 것을 촉발하기 위해서 뿐만 아니라 발생했는지를 그리고 발생할 때를 자격검증하기 위해 서비스에 의해 사용될 수 있다. 실행 기준들은, 하나 이상의 특정된 SL 속성 또는 메타데이터에 대한 임계치/값, 이력뿐만 아니라 현재 조건들, 이를테면 하나 이상의 디바이스의 상태 또는 하나 이상의 리소스의 상태의 분석에 기반한 SL 정의 경우, SL이 애플리케이션 또는 제3자 서비스 또는 기본 네트워크로부터 수신하거나 검출한 외부 촉발 조건, 또는 다른 SL 트랜잭션의 성공적인 완료를 포함할 수 있다.
애플리케이션들이 DSLT 또는 DSLT들의 시퀀스에 대한 재송신 정책들을 정의할 수 있게 하는 DSLT 서비스의 능력에 관하여, 다음과 같다. 재송신 정책들은, DSLT(들)의 실패한 실행이 서비스가 DSLT(들)를 재시도하는 것을 초래했는지를 그리고 초래한 때를 자격검증하기 위해 서비스에 의해 사용될 수 있다.
애플리케이션들이 DSLT 또는 DSLT들의 시퀀스에 대한 완료 기준들을 정의할 수 있게 하는 DSLT 서비스에 대한 능력에 관하여, 다음과 같다. 완료 기준들은, DSLT(들)를 구성하는 개별 요청들의 결과들에 따라 DSLT(들)의 실행이 성공적인지 아닌지를 그리고 그러한 때를 자격검증하기 위해 서비스에 의해 사용될 수 있다. 예컨대, 성공적인 완료는 특정 시간 윈도우 내에서의 완료를 요구할 수 있거나, 일부 DSLT들은 요청들의 하위 세트만이 성공적으로 완료될 것을 요구할 수 있지만, 다른 DSLT들은 그들 전부가 성공적일 것을 요구할 수 있다.
애플리케이션들이 DSLT 또는 DSLT들의 시퀀스에 대한 우선순위를 정의할 수 있게 하는 DSLT 서비스에 대한 능력에 관하여, 우선순위는, 필요한 경우 및 필요할 때(예컨대, DSLT들이 동일한 표적들을 공유하고 그들의 실행이 직렬화되어야 할 때) 서로에 대해 DSLT(들)를 순위화하고 이러한 순위에 기반하여 그들의 실행을 순서화하기 위해 서비스에 의해 사용될 수 있다.
DSLT 또는 DSLT들의 시퀀스를 개시하기 위해 간단한 레스트풀 API를 애플리케이션들에 제공하는 DSLT 서비스의 능력에 관하여, API는 각각의 DSLT에 대한 SL 트랜잭션 식별자를 정의할 수 있다. API는 DSLT들의 시퀀스에 대한 SL 시퀀스 식별자를 정의할 수 있다. 그리고, API는, 애플리케이션들로부터의 비-차단 요청들이 DSLT 또는 DSLT들의 시퀀스를 개시하거나, 그 상태를 질의하거나, 또는 그를 중단하는 능력을 지원할 수 있다.
도 11은 애플리케이션의 관점에서 개시된 DSLT 서비스로 달성될 수 있는 복잡성의 감소를 예시한다.
도 11의 단계(1)에서, 애플리케이션(1002)은 트랜잭션에 대한 요청을 서버(1102)에 전송한다. 서버(1102)는 DSLT 서비스를 포함하는 서비스 계층을 갖는 IoT 서버(1102)일 수 있다. 서버(1102)는 트랜잭션의 관리를 담당한다. (도 10에서 행해진 바와 같이) 애플리케이션(1002)으로부터 서버(1102)로 트랜잭션의 관리를 이동시킴으로써, 애플리케이션(1002)에서의 동작들이 간략화될 수 있다.
도 11의 단계(2)에서, 서버(1102)는 다수의 디바이스들(1004, 1006, 및 1008)에 DSLT 요청을 배포한다.
도 11의 단계(3)에서, 디바이스들(1004, 1006, 및 1008)은, 그들이 트랜잭션을 성공적으로 실행할 수 있는지를 확인한다.
도 11의 단계(4)에서, 디바이스들(1004, 1006, 및 1008)은, 서버에 응답하여 그들이 트랜잭션을 실행할 수 있는지를 표시한다. 이러한 예에서, 디바이스들 중 하나(디바이스(1008))는 트랜잭션을 실행할 수 없다.
도 11의 단계(5)에서, 디바이스들 중 하나(디바이스(1008))가 트랜잭션을 실행할 수 없으므로, 다른 디바이스들(디바이스(1004 및 1006))에서 트랜잭션이 중단된다.
도 11의 단계(6)에서, 서버(1102)는 애플리케이션(1002)에 응답을 전송한다.
도 11을 도 10과 비교하면, DSLT를 관리하는 IoT 애플리케이션(1002) 상의 오버헤드 및 복잡성이 크게 감소된다. 설명된 DSLT 서비스를 이용하여, IoT 애플리케이션(1002)은 단일 요청 및 응답으로 DSLT를 수행할 수 있는 반면, 기존의 해결책들에서는, 각각의 트랜잭션의 상태를 관리하기 위해 더 많은 메시지들 및 더 많은 내부 논리를 요구한다.
개시된 DSLT 서비스의 추가적인 세부사항들이 이후 설명된다.
DSLT 아키텍처
일 실시예에서, DSLT 서비스는, 분산형 서비스 계층 트랜잭션 촉발 기능(DSLT-TF)(1202), 분산형 서비스 계층 트랜잭션 관리 기능(DSLT-MF)(1204 및 1206), 및 분산형 서비스 계층 트랜잭션 클라이언트 기능(DSLT-CF)(1208, 1210, 1212 및 1214)을 포함할 수 있다.
DSLT-TF(1202)는, DSLT-MF(1204)가 DSLT-REQ들(1218)을 배포 및 관리할 수 있도록 DSLT-MF(1204)에 대해 DSLT 촉발 요청(DSLT-TRIGGER)(1216)을 개시하는 데 사용될 수 있다. DSLT-TF(1202)는, IoT 서버들, IoT 게이트웨이들, IoT 디바이스들, 및 IoT 애플리케이션들과 같은 다양한 유형들의 네트워크 노드들 상에서 호스팅될 수 있는 가볍고 얇은 기능인 것을 의미한다.
DSLT-MF(1204)(및 1206)는 서비스로서 구현될 수 있다. 서비스는 독립형 서비스일 수 있거나 IoT 서비스 계층의 하위 서비스로서 구현될 수 있다. DSLT-MF 서비스(1204)는, IoT 서버들, IoT 게이트웨이들, 및 IoT 디바이스들과 같은 다양한 유형들의 네트워크 노드들 상에서 호스팅될 수 있다. DSLT-MF 서비스(1204)는, DSLT-CF들의 분산된 세트에 DSLT들의 배포 및 처리를 촉발하기 위한 요청들을 수신할 수 있다. DSLT-MF(1204)에 의해 수신되는 각각의 DSLT-TRIGGER은 하나 이상의 표적을 표적화하는 하나 이상의 SL 동작으로 이루어질 수 있다. DSLT-MF(1204)는 원자적 방식으로 자신의 연관된 SL 요청들 전부를 처리함으로써 DSLT-TRIGGER(1216)을 처리한다. 요구되는 경우, DSLT-MF(1204)는, DSLT-TRIGGER(1216)에 의해 특정된 SL 요청(들)이 SL 엔티티들의 분산된 세트에 적절하게 배포되어 모든 표적화된 SL 엔티티들에 의해 성공적으로 실행되거나 실패들의 경우에서는 그들 중 어느 것도 실행되지 않음을 보장한다. 명확화를 위해, DSLT-MF(1204)로부터 DSLT-CF(1208 및 1210)로 배포된 DSLT 요청은 DSLT-REQ(1218)로 지칭된다.
DSLT-CF(1210)는 표적으로서 기능하고, 자신이 DSLT-MF(1204)로부터 수신한 배포된 DSLT-REQ(1218)를 처리한다. DSLT-CF(1208)는, IoT 서버들, IoT 게이트웨이들, IoT 디바이스들 및 IoT 애플리케이션들과 같은 다양한 유형들의 네트워크 노드들 상에서 호스팅될 수 있다.
예컨대, 도 12에 도시된 바와 같이, DSLT-TF(1202)를 지원하는 IoT 애플리케이션(1230)은, IoT 서버(1232) 상에서 호스팅되는 DSLT-MF(1204)에 DSLT-TRIGGER(1216)을 전송하여, 원자적 DSLT-REQ들(1218 및 1219)의 세트를 배포하게 함으로써, IoT 디바이스들(1234 및 1236)의 분산된 세트 상의 액추에이터(예컨대, 전자 스위치)를 업데이트할 수 있다. DSLT-MF(1204)는 결국, 각각의 디바이스 상에서 호스팅되는 DSLT-CF들(1208 및 1210)에 DSLT-REQ들(1218 및 1219)을 배포할 수 있고, 또한, 그들 전부가 DSLT-REQ들(1218 및 1219)을 성공적으로 수행하여 자신의 액추에이터들을 업데이트하거나 그들 중 어느 것도 업데이트를 수행하지 않음을 보장할 수 있다. 그렇게 함으로써, 모든 디바이스들 상의 설정들이 일관되게 유지된다.
도 12에 도시된 바와 같이, IoT 게이트웨이 및 IoT 디바이스(1238 및 1240)를 수반하는 것과 같은 다중-홉 시나리오의 경우에서, IoT 게이트웨이(1242) 상의 DSLT-MF(1206)는 IoT 서버의 DSLT-MF(1204)로부터 배포된 DSLT-TRIGGER(1222)를 수신하는 데 사용될 수 있다. 그 DSLT-TRIGGER이 IoT 디바이스(1238 및 1240)에 의해 호스팅되는 리소스들을 표적화한다는 것을 검출할 시, IoT 게이트웨이의 DSLT-MF(1206)는, IoT 디바이스들의 DSLT-CF들(1212 및 1214) 둘 모두에 DSLT-REQ들(1224 및 1226)을 배포하는 데 사용될 수 있다. 이는, DSLT 서비스의 분산형 속성, 및 다수의 DSLT-MF들이 사용되어 시스템 전체에 걸쳐 DSLT들을 원자적으로 처리할 수 있는 방식을 나타낸다.
DSLT-TF(1202)는, DSLT-MF(1204)에 DSLT 요청들을 개시하고 DSLT-MF(1204)로부터 반환되는 DSLT 응답들을 수신하는 능력을 지원할 수 있다. 임의의 다른 DLST 처리 능력들을 지원하는 것이 요구되지는 않는다.
DSLT-MF(1204)는 DSLT들을 처리하기 위한 몇몇 능력들을 지원할 수 있다. DSLT-MF 능력들의 세트가 도 13에 도시된다. DSLT-MF(1204)는, DSLT-MF API(1302), DSLT-MF 처리(1304), DSLT-MF 시퀀스 처리(1306), DSLT-MF 정책 엔진(1308), 및 DSLT-MF 스케줄러(1310)를 포함할 수 있다.
유사하게, DSLT-CF(1210)는, 도 14에 도시된 바와 같이, DSLT들을 처리하기 위한 대응하는 능력들의 세트를 지원할 수 있다. DSLT-CF(1210)는, DSLT-CF API(1402), DSLT-CF 처리(1404), 및 DSLT-CF 시퀀스 처리(1406)를 포함할 수 있다.
다음의 하위 항목들은 DSLT-MF(1204) 및 DSLT-CF(1210) 능력들 각각의 추가적인 정의를 제공한다.
DSLT API들
DSLT-MF(1204)는, DSLT-MF(1204)에 DSLT 관련 요청들을 개시하기 위해 DSLT-TF들에 의해 사용될 수 있는 API(1302)를 지원할 수 있다. 지원되는 요청들의 유형들은, 새로운 DSLT를 개시하는 것(즉, DSLT-TRIGGER), 기존 DSLT의 상태에 대해 질의하는 것(즉, DSLT-QUERY), 및 미해결 DSLT를 중단하는 것(DSLT-ABORT)을 포함할 수 있다. API(1302)는 또한, DSLT-MF가 DSLT들을 처리하고 스케줄링하는 방식을 제어하기 위한 규칙들을 정의하는 정책들을 구성하는 데 사용될 수 있다. 이러한 API(1302)는 DSLT 관련 메시지 파라미터들 및/또는 DSLT-MF(1204)에 의해 호스팅되는 리소스들로 이루어지는 레스트풀 인터페이스로서 지원될 수 있다.
DSLT-CF(1210)가 또한 API(1402)를 지원할 수 있다. 이러한 API(1402)는 DSLT-CF(1210)에 DSLT 관련 요청들을 전송하기 위해 DSLT-MF(1204)에 의해 사용될 수 있다. 지원되는 요청들의 유형들은, DSLT-CF(1210)에 새로운 DSLT를 전달하는 것(즉, DSLT-REQ), 기존 DSLT의 상태에 대해 질의하는 것(DSLT-QUERY), 및 DSLT-CF(1210)가 처리 중인 미해결 DSLT를 중단하는 것(DSLT-ABORT)을 포함할 수 있다. 이러한 API(1402)는 DSLT 관련 메시지 파라미터들 및/또는 DSLT-CF(1210)에 의해 호스팅되는 리소스들로 이루어지는 레스트풀 인터페이스로서 지원될 수 있다.
DSLT API 리소스들:
일 예에서, 다음의 유형들의 리소스들이 DSLT-MF(1204)에 의해 지원될 수 있다.
Figure pct00002
Figure pct00003
DSLT API 메시지 파라미터들
DSLT 메시지 파라미터들은, DSLT-TRIGGER, DSLT-SEQ-TRIGGER, DSLT-REQ, DSLT-QUERY 및 DSLT-ABORT와 같은 다양한 유형들의 DSLT 메시지들에 적용가능할 수 있다. 이러한 다양한 DSLT 메시지 유형들은 레스트풀 API에 맵핑될 수 있으며, 여기서, 각각의 DSLT 메시지 유형은 CRUD 동작 및 일부 DSLT 메시지 파라미터들을 사용하여 구현될 수 있다.
Figure pct00004
단일 DSLT 요청에 부가하여, 2개 이상의 DSLT가 조합되어 DSLT 시퀀스를 형성할 수 있다. DSLT 시퀀스는 DSLT들의 순서화된 목록을 특정한다. 다수의 DSLT들이 단일 SL 요청으로 함께 배칭(batch)될 수 있거나, 대안적으로는, DSLT들의 시퀀스가 동일한 값을 갖는 DSLT 시퀀스 식별자를 사용하여 서로 연관될 수 있다. DSLT-MF(1204) 및 DSLT-CF(들)(1210 및 1208)는 함께, DSLT 시퀀스를 원자적으로 처리 및 실행할 수 있다. 처리는, 개별 DSLT들의 원자적 실행뿐만 아니라 전체 시퀀스의 원자적 처리를 포함한다. 그러므로, 개별 DSLT들 중 임의의 DSLT가 성공적으로 완료되지 않는 경우, DSLT-MF(1204) 및 DSLT-CF(1210 및 1208)가 시퀀스 내의 모든 DSLT들의 롤백을 지원할 수 있어서, DSLT 시퀀스에 의해 표적화된 임의의 리소스들은, DSLT 시퀀스의 실행이 시작되기 전에 자신이 있던 그들의 동일한 원래의 상태로 복귀된다.
다음은, DSLT 시퀀스와 관련된 메시지 파라미터들의 세트이다.
Figure pct00005
Figure pct00006
DSLT API 식별자들
개별 DSLT에 대한 SL 식별자가 표 7에 도시된다. DSLT들의 시퀀스에 대한 식별자가 표 6에 도시된다. 이러한 DSLT 식별자들의 구조는 표 5에 도시된 바와 같은 다수의 구성요소들로 이루어질 수 있다. 식별자들은, 서비스 제공자 구성요소(SP-ID), DSLT-MF 구성요소(DSLT-MF-ID), DSLT 시퀀스 구성요소(DSLT-SEQ-ID), DSLT 구성요소(DSLT-ID), 및 SL 요청 ID 구성요소(SL-REQ-ID)로 이루어질 수 있다.
시스템에서 DSLT가 사용되는 곳에 따라, 상이한 포맷들 및 고유성 요건들이 존재할 수 있다. 예컨대, DSLT-MF(1204)가 호스팅되고 있는 것과 동일한 IoT 서비스 제공자 도메인 내에서 호스팅되는 DSLT-CF들을 표적화하기 위해서만 DSLT가 사용되는 경우, DSLT 식별자의 고유성 요건들은 SP-ID 구성요소를 요구하지 않을 수 있다. 반면, DSLT-MF(1204)와 상이한 IoT 서비스 제공자 도메인에서 호스팅되는 DSLT-CF들을 DSLT가 표적화하는 경우, DSLT는 SL 인스턴스들에 걸쳐 그리고 서비스 제공자 도메인들에 걸쳐 고유한 식별자를 요구할 수 있으며, SP-ID를 포함할 수 있다.
Figure pct00007
Figure pct00008
Figure pct00009
DSLT 처리 능력
개별 DSLT를 처리하기 위한 방법 및 DSLT들의 시퀀스를 처리하기 위한 방법이 아래에 설명된다. 이러한 방법들 각각은, DSLT-TF(1202), DSLT-MF(1204), 및 DSLT-CF(1210)에 의해 수행되는 동작들을 갖는다. 개개의 동작들은 아래의 설명에서 명확해진다.
개별 DSLT 처리
개별 DSLT는, DSLT-TF(1202)가 DSLT-MF(1204)에 DSLT-TRIGGER 요청(1216)을 전송함으로써 개시되는 하나의 DSLT로 이루어질 수 있다. 그런 다음, DSLT-MF(1204)는 DSLT-TRIGGER 요청(1216)을 처리한다. 이러한 처리는, DSLT-MF(1204)가 다수의 DSLT-REQ들(1218 및 1219)을 DSLT의 표적들인 SL 엔티티들의 분산된 세트에 배포하는 것을 수반할 수 있다. DSLT-REQ를 수신하는 각각의 SL 엔티티는 DSLT-REQ를 처리할 수 있는 DSLT-CF(1208 및 1210)를 호스팅한다. DSLT-MF(1204)는, DSLT-REQ들의 배포된 세트(1219 및 1218)를 그들이 원자적 방식으로 처리됨을 보장하도록 관리한다. 완료할 때, DSLT-MF(1204)는, DSLT-TRIGGER 요청(1216)을 발신한 DSLT-TF(1202)에 응답을 반환한다. 이러한 응답은 DSLT의 결과들을 포함한다.
개별 DSLT를 처리하기 위한 전체 방법은, DSLT-TF(1202)가 DSLT를 개시하고, DSLT-MF(1204)가 DSLT의 처리를 관리하고, DSLT-CF들(1208 및 1210)이 표적화된 리소스들 상에서 DSLT에 특정된 동작들을 수행하는 것으로 이루어지는 3개의 상보적인 방법으로 세분될 수 있다. 각각의 이러한 방법들의 설명들이 다음의 흐름도들에서 포착된다.
도 15는, 개별 DSLT에 대한 DSLT-TF 처리를 도시한다.
도 15의 단계(1)에서, DSLT 촉발 조건(예컨대, 애플리케이션 특정 경우)이 DSLT-TF(1202)를 호스팅하는 SL 엔티티(예컨대, 애플리케이션)(1230) 상에서 발생한다.
도 15의 단계(2)에서, DSLT-TF(1202)가 DSLT-TRIGGER 요청을 생성하여 그 요청을 DSLT-MF(1204)를 호스팅하는 SL 엔티티에 전송하며, 따라서, DSLT-MF(1204)가 그 대신에 DSLT 처리를 수행할 수 있다. DSLT-TF(1202)는, DSLT-MF(1204)가 다시 응답하여 DSLT 처리가 완료됨을 표시하는 것을 대기한다.
도 15의 단계(3a)에서, DSLT-MF(1204)는, DSLT 처리가 완료됨을 DSLT-TF(1202)에 다시 응답하며, 이는, 이러한 처리의 상태를 포함한다.
도 15의 단계(3b)에서, DSLT-TF(1202)가 DSLT-MF(1204)로부터의 응답들을 대기하면서 타임아웃된다. DSLT-TF(1202)는 DSLT-TRIGGER를 DSLT-MF(1204)에 재전송함으로써 DSLT를 재시도한다.
도 15의 단계(3c)에서, DSLT-TF(1202)는 DSLT 요청을 중단하기로 결정한다. 이러한 결정은, DSLT-TF(1202)가 타임아웃 이후에 재시도하기를 원하지 않는다고 결정하는 것의 결과일 수 있다. 또는, 이러한 결정은, 애플리케이션 특정 이유와 같은 다른 인자들에 기반할 수 있다.
도 15의 단계(4)에서, DSLT-TF(1202)는, DSLT-MF(1204)에 의해 자신에게 반환되는 DSLT 결과들을 확인한다.
도 15의 단계(5a)에서, DSLT는 DSLT-MF(1204)에 의해 성공적으로 처리되었다. DSLT-TF(1202)는 DSLT가 완료된 것으로 간주할 수 있다.
도 15의 단계(5b)에서, DSLT는 성공적으로 처리되지 않았다. DSLT-TF(1202)는, DSLT-TRIGGER 요청을 DSLT-MF(1204)에 재송출하여 DSLT-MF(1204)가 DSLT의 처리를 다시 재시도하게 함으로써 DSLT를 재시도하기로 결정한다.
도 15의 단계(5c)에서, DSLT는 성공적으로 처리되지 않았다. 재시도하기 보다는, DSLT-TF(1202)는 DSLT 요청을 중단하기로 결정한다.
도 15의 단계(6)에서, DSLT는 성공적으로 처리되었고, DSLT-TF(1202)는 DSLT 촉발 요청을 호출한 엔티티(예컨대, 애플리케이션)에 결과들을 반환한다.
도 15의 단계(7)에서, DLST-TF는 DSLT를 중단하기로 결정한다. DSLT-TF(1202)가 DSLT-MF(1204)로부터 응답을 수신했는지 아니지의 여부에 따라, DSLT-TF(1202)는, 자신이 DSLT를 중단하기로 결정했음을 DSLT-MF(1204)에 통지하기 위해 DSLT-MF(1204)에 중단 요청을 전송하기로 결정할 수 있다.
도 16은, 개별 DSLT에 대한 DSLT-MF(1204) 처리를 도시한다.
도 16의 단계(1)에서, DSLT-TF(1202)를 호스팅하는 SL 엔티티는, DSLT를 개시하기 위해, DSLT-MF(1204)를 호스팅하는 SL 엔티티에 DSLT-TRIGGER 요청을 전송한다.
도 16의 단계(2)에서, DSLT-MF(1204)는 요청을 처리하고, DSLT-TRIGGER에 의해 표적화된 DSLT-CF들(1208 및 1210) 각각에 DSLT-REQ를 배포한다. DSLT-MF(1204)는, DSLT-CF들(1208 및 1210) 각각으로부터, 그들이 표적화된 리소스들에 대한 잠금들을 성공적으로 획득했음을 표시하는 응답들을 대기한다.
도 16의 단계(3a)에서, DSLT-MF(1204)는 DSLT-CF들(1208 및 1210) 전부(또는 정의된 완료 기준들에 따라 하위 세트)가 표적화된 리소스들에 대한 잠금들을 성공적으로 획득할 수 있었음을 검출한다.
도 16의 단계(3b)에서, DSLT-MF(1204)가 하나 이상의 DSLT-CF(1208 및 1210)로부터의 응답들을 대기하면서 타임아웃된다. DSLT-MF(1204)는 DSLT-REQ를 타임아웃된 하나 이상의 DSLT-CF에 재전송함으로써 DSLT를 재시도한다.
도 16의 단계(3c)에서, DSLT-MF(1204)는 DSLT 요청을 중단하기로 결정한다. 이러한 결정은, DSLT-MF(1204)가 타임아웃 이후에 재시도하기를 원하지 않는다고(예컨대, 최대 재시도 횟수에 도달했다고) 결정하는 것의 결과일 수 있다. DSLT-MF(1204)가 하나 이상의 DSLT-CF가 표적화된 리소스(들)에 대한 잠금들을 성공적으로 획득할 수 없었다는 것을 검출하는 경우, DSLT-MF(1204)는, DSLT가 모든 표적화된 DSLT-CF들(1208 및 1210)에 걸쳐 원자적으로 수행될 수는 없으므로 (정의된 완료 기준들에 따라) DSLT를 중단하기로 선택할 수 있다. DSLT-MF(1204)는 각각의 DSLT-CF에 실행 명령을 전송하지 않기로 선택하고 DSLT가 타임아웃되게 놓아둠으로써 DSLT를 중단할 수 있거나, DSLT-MF(1204)는 각각의 DSLT-CF에 중단 명령을 명시적으로 전송할 수 있다. 중단 결정은 또한, 하나 이상의 DSLT-CF가 도달가능하지 않다는 것과 같은 다른 인자들에 기반할 수 있다.
도 16의 단계(4)에서, DSLT-MF(1204)는, 실행 명령을 DSLT-CF들(1208 및 1210)에 전송함으로써, DSLT에 의해 특정된 동작을 실행할 것을 DSLT-CF들에 지시한다. DSLT-MF(1204)는, DSLT-CF들 각각으로부터, 그들이 표적화된 리소스들에 대한 동작들을 성공적으로 실행했음을 표시하는 응답들을 대기한다.
도 16의 단계(5a)에서, DSLT-MF(1204)는 DSLT-CF들 전부(또는 정의된 완료 기준들에 따라 하위 세트)가 표적화된 리소스들 상에서 DSLT에 의해 특정된 동작들을 성공적으로 실행할 수 있었음을 검출한다.
도 16의 단계(5b)에서, DSLT-MF(1204)가 하나 이상의 DSLT-CF(1208 및 1210)로부터의 응답들을 대기하면서 타임아웃된다. DSLT-MF(1204)는 실행 명령을 타임아웃된 하나 이상의 DSLT-CF에 전송하는 것을 재시도한다.
도 16의 단계(5c)에서, DSLT-MF(1204)는 DSLT 요청을 중단하기로 결정한다. 이러한 결정은, DSLT-MF(1204)가 타임아웃 이후에 재시도하기를 원하지 않는다고(예컨대, 최대 재시도 횟수에 도달했다고) 결정하는 것의 결과일 수 있다. 또는, 이러한 결정은, 하나 이상의 DSLT-CF가 도달가능하지 않다는 것과 같은 다른 인자들에 기반할 수 있다. DSLT-MF(1204)가 하나 이상의 DSLT-CF가 표적화된 리소스(들) 상에서 동작들을 성공적으로 실행할 수 없었다는 것을 검출하는 경우, DSLT-MF(1204)는, DSLT가 모든 표적화된 DSLT-CF들(1208 및 1210)에 걸쳐 원자적으로 수행될 수는 없으므로 (정의된 완료 기준들에 따라) DSLT를 중단하기로 선택할 수 있다. DSLT-MF(1204)는 각각의 DSLT-CF(1208 및 1210)에 실행 명령을 전송하지 않기로 선택하고 DSLT가 타임아웃되게 놓아둠으로써 DSLT를 중단할 수 있거나, DSLT-MF(1204)는 각각의 DSLT-CF(1208 및 1210)에 중단 명령을 명시적으로 전송할 수 있다.
도 16의 단계(6)에서, DSLT-MF(1204)는, DSLT에 의해 특정된 동작을 커밋할 것을 DSLT-CF들(1208 및 1210)에 지시한다. DSLT-MF(1204)는, DSLT-CF들(1208 및 1210) 각각으로부터, 그들이 표적화된 리소스들 상에서 동작들을 성공적으로 커밋했음을 표시하는 응답들을 대기한다.
도 16의 단계(7a)에서, DSLT-MF(1204)는 DSLT-CF들(1208 및 1210) 전부(또는 정의된 완료 기준들에 따라 하위 세트)가 표적화된 리소스들 상에서 DSLT에 의해 특정된 동작들의 결과들을 성공적으로 커밋할 수 있었음을 검출한다.
도 16의 단계(7b)에서, DSLT-MF(1204)가 하나 이상의 DSLT-CF(1208 및 1210)로부터의 응답들을 대기하면서 타임아웃된다. DSLT-MF(1204)는 커밋 명령을 타임아웃된 하나 이상의 DSLT-CF(1208 및 1210)에 전송하는 것을 재시도한다.
도 16의 단계(7c)에서, DSLT-MF(1204)는 DSLT 요청을 중단하기로 결정한다. 이러한 결정은, DSLT-MF(1204)가 타임아웃 이후에 재시도하기를 원하지 않는다고(예컨대, 최대 재시도 횟수에 도달했다고) 결정하는 것의 결과일 수 있다. 또는, 이러한 결정은, 하나 이상의 DSLT-CF(1208 및 1210)가 도달가능하지 않다는 것과 같은 다른 인자들에 기반할 수 있다.
도 16의 단계(8)에서, DSLT는 성공적으로 처리되었고, DSLT-MF(1204)는 DSLT를 촉발한 DSLT-TF(1202)에 결과들을 반환한다.
도 16의 단계(9)에서, DLST-MF는 DSLT를 중단하기로 결정한다. DSLT-MF(1204)가 DSLT-CF들(1208 및 1210)로부터 응답을 수신했는지 아닌지 여부에 따라, DSLT-MF(1204)는 자신이 DSLT를 중단하기로 결정했음을 하나 이상의 DSLT-CF(1208 및 1210)에 통지하기 위해 하나 이상의 DSLT-CF(1208 및 1210)에 명시적 중단 요청을 전송하기로 결정할 수 있으며, 따라서, 하나 이상의 DSLT-CF(1208 및 1210)는, DSLT의 처리를 중단하는 것, 표적화된 리소스의 상태를 그의 원래의 상태로 롤백하는 것, 또는 표적화된 리소스를 잠금해제하는 것과 같은 임의의 필요한 처리를 수행할 수 있다.
도 17은, 개별 DSLT-CF에 대한 DSLT-CF 처리를 도시한다.
도 17의 단계(1)에서, DSLT-CF(1210)를 호스팅하는 SL 엔티티는, DSLT-MF(1204)로부터 DSLT-REQ를 수신한다.
도 17의 단계(2)는, DSLT-CF(1210)가 요청된 리소스를 잠그려 시도하는 초기화 단계이다.
도 17의 단계(3a)에서, DSLT-CF(1210)는 DSLT-REQ에 의해 표적화된 리소스(들)에 대한 잠금을 (요구되는 경우) 성공적으로 획득할 수 있다. 이러한 차단은, 심지어 잠금된 리소스의 상태가 커밋되고 잠금해제될 때까지 잠금된 리소스의 검색이 차단될 필요가 있을 수 있으므로, 다른 DSLT-REQ들로부터의 모든 동작들에 적용가능해질 수 있다.
도 17의 단계(3b)에서, DSLT-CF(1210)는 타임아웃 기간이 경과하기 전에는 표적화된 리소스에 대한 잠금을 획득할 수 없으며, 그러므로, DSLT-CF(1210)는 DSLT-REQ를 타임아웃하고 중단하기로 선택한다. DSLT-CF(1210)는 이러한 타임아웃을 DSLT-MF(1204)에 통지할 수 있다. 타임아웃에 후속하여, DSLT-CF(1210)는 DSLT-MF(1204)로부터 재시도된 DSLT-REQ를 수신할 수 있으며, 이러한 경우에, DSLT-CF(1210)는 단계(1)로 시작하는 흐름을 반복할 수 있다.
도 17의 단계(3c)에서, DSLT-CF(1210)는 DSLT-MF(1204)로부터 명시적 중단 명령을 수신하며, 그러므로, DSLT-CF(1210)는 DSLT-REQ를 중단한다. DSLT-CF(1210)가 표적화된 리소스들 중 임의의 리소스에 대해 잠금들을 획득할 수 있었던 경우, DSLT-CF(1210)는 이러한 잠금들을 해제하고 DSLT의 처리를 중단한다. DSLT-CF는 DSLT-MF(1204)로부터 재시도된 DSLT-REQ를 수신할 수 있으며, 이러한 경우에, DSLT-CF는 단계(1)로 시작하는 흐름을 반복할 수 있다.
도 17의 단계(4)에서, 표적화된 리소스(들)에 대한 잠금이 (요구되는 경우) 각각의 DSLT-CF에 의해 획득된다. 각각의 DSLT-CF는, 잠금이 획득되었다는 것 또는 요구되지 않는다는 것을 DSLT-MF(1204)에 통지한다. DSLT-CF(1210)는, 표적화된 리소스(들) 상에서 DSLT 특정된 동작(들)을 실행하기 위한 DSLT-MF(1204)로부터의 명령을 수신할 때까지 이러한 상태에서 대기한다.
도 17의 단계(5a)에서, DSLT-CF(1210)는 DSLT-MF(1204)로부터 실행 명령을 수신했으며, 표적화된 리소스(들) 상에서 DSLT 특정된 동작(들)의 실행을 성공적으로 완료할 수 있었다.
도 17의 단계(5b)에서, DSLT-CF(1210)는 타임아웃 기간이 경과하기 전에는 DSLT-MF(1204)로부터 실행 명령을 수신하지 않으며, 그러므로, DSLT-CF(1210)는 DSLT-REQ를 타임아웃하고 리소스를 잠금해제한다. DSLT-CF(1210)는 이러한 타임아웃을 DSLT-MF(1204)에 통지할 수 있다. 타임아웃에 후속하여, DSLT-CF(1210)는 DSLT-MF(1204)로부터 DSLT-REQ 명령을 수신할 수 있다.
도 17의 단계(5c)에서, DSLT-CF(1210)는 DSLT-REQ의 실행을 중단한다. 이는, DSLT-MF(1204)로부터 실행 명령을 수신하고 표적화된 리소스(들) 상에서 DSLT 특정된 동작(들)을 성공적으로 실행할 수 없는 것의 결과일 수 있다. 대안적으로, 이는, DSLT-CF(1210)가 DSLT-MF(1204)로부터 중단 명령을 수신하는 것의 결과일 수 있다.
도 17의 단계(6)에서, DSLT-CF(1210)는 실행을 성공적으로 완료했다. DSLT는 자신의 실행 상태를 DSLT-MF(1204)에 통지하고, DSLT-MF(1204)로부터의 커밋 명령을 대기한다.
도 17의 단계(7a)에서, DSLT-CF(1210)는 DSLT-MF(1204)로부터 커밋 명령을 수신했으며, 결과들이 지속적으로 유지되도록 표적화된 리소스의 상태를 성공적으로 커밋할 수 있었다.
도 17의 단계(7b)에서, DSLT-CF(1210)는 타임아웃 기간이 경과하기 전에는 DSLT-MF(1204)로부터 커밋 명령을 수신하지 않으며, 그러므로, DSLT-CF(1210)는 DSLT-REQ를 타임아웃한다. DSLT-CF(1210)는 다른 DSLT-CF들과 일관되게 유지하기 위해, 중단하기 보다는 업데이트된 리소스(들)의 상태를 계속 커밋한다. DSLT-CF(1210)는 또한 리소스를 잠금해제한다.
도 17의 단계(7c)에서, DSLT-CF(1210)는 DSLT-REQ의 커밋을 중단한다. 이는, DSLT-MF(1204)로부터 커밋 명령을 수신하고 결과들을 성공적으로 커밋할 수 없는 것의 결과일 수 있다. 대안적으로, 이는, DSLT-CF(1210)가 DSLT-MF(1204)로부터 중단 명령을 수신하는 것의 결과일 수 있다.
도 17의 단계(8)에서, 커밋에 후속하여, DSLT-CF(1210)는 DSLT에 의해 표적화된 리소스(들)에 대한 잠금을 해제할 수 있다. 이러한 경우에서, DSLT-CF(1210)는 또한 DSLT-MF(1204)에 커밋의 통지를 전송할 수 있다.
도 17의 단계(9)에서, DSLT-CF(1210)는 DSLT를 중단 및 롤백하고 대응하는 상태를 DSLT-MF(1204)에 반환한다. 중단에 후속하여, DSLT-CF는 리소스에 대한 잠금을 해제해야 한다. 이러한 경우에서, DSLT-CF(1210)는 또한 DSLT-MF(1204)에 중단의 통지를 전송할 수 있다.
DSLT 시퀀스 처리
DSLT들의 시퀀스는, 원자적이고 순서화된 세트로서 처리되어야 하는 다수의 분산형 서비스 계층 트랜잭션들로 이루어진다. DSLT 시퀀스는, DSLT-TF(1202)가 DSLT-MF(1204)에 DSLT-SEQ-TRIGGER 요청을 전송함으로써 촉발된다. 그런 다음, DSLT-MF(1204)는 DSLT 시퀀스를 처리한다. 이러한 처리는, DSLT-MF(1204)가 DSLT-REQ들을 DSLT 시퀀스의 표적들인 SL 엔티티들의 분산된 세트에 배포하는 것을 수반할 수 있다. DSLT-REQ를 수신하는 각각의 SL 엔티티는 DSLT-REQ를 처리할 수 있는 DSLT-CF(1208 및 1210)를 호스팅한다. DSLT-MF(1204)는, 시퀀스 내의 DSLT-REQ들 전부가 원자적이고 순서화된 방식으로 처리된다는 것을 보장한다. 완료할 때, DSLT-MF(1204)는, DSLT-SEQ-TRIGGER 요청을 발신한 DSLT-TF(1202)에 응답을 반환한다. 이러한 응답은 DSLT 시퀀스의 결과들을 포함한다.
DSLT 시퀀스를 처리하기 위한 전체 방법은, DSLT-TF(1202)가 DSLT 시퀀스를 개시하고, DSLT-MF(1204)가 DSLT 시퀀스의 처리를 관리하고, DSLT-CF들(1208 및 1210)이 시퀀스 내의 개별 DSLT들에 의해 특정된 표적화된 리소스들 상에서 동작들을 수행하는 것으로 이루어지는 3개의 상보적인 방법으로 세분될 수 있다. 각각의 이러한 방법들의 설명들이 다음의 흐름도들에서 포착된다.
도 18은, DSLT 시퀀스에 대한 DSLT-TF(1202) 처리를 도시한다.
도 18의 단계(1)에서, DSLT 시퀀스 촉발 조건(예컨대, 애플리케이션 특정 경우)이 DSLT-TF(1202)를 호스팅하는 SL 엔티티(예컨대, 애플리케이션) 상에서 발생한다.
도 18의 단계(2)에서, DSLT-TF(1202)가 DSLT-SEQ-TRIGGER 요청을 생성하여 그 요청을 DSLT-MF(1204)를 호스팅하는 SL 엔티티에 전송하며, 따라서, DSLT-MF(1204)가 그 대신에 DSLT 시퀀스 처리를 수행할 수 있다. DSLT-TF(1202)는, DSLT-MF(1204)가 다시 응답하여 DSLT 시퀀스 처리가 완료됨을 표시하는 것을 대기한다.
도 18의 단계(3a)에서, DSLT-MF(1204)는, DSLT 시퀀스 처리가 완료됨을 DSLT-TF(1202)에 다시 응답하며, 이는, 이러한 처리의 상태를 포함한다.
도 18의 단계(3b)에서, DSLT-TF(1202)가 DSLT-MF(1204)로부터의 응답들을 대기하면서 타임아웃된다. DSLT-TF(1202)는 DSLT-SEQ-TRIGGER 요청을 DSLT-MF(1204)에 재전송함으로써 DSLT 시퀀스를 재시도한다.
도 18의 단계(3c)에서, DSLT-TF(1202)는 DSLT-SEQ-TRIGGER 요청을 중단하기로 결정한다. 이러한 결정은, DSLT-TF(1202)가 타임아웃 이후에 재시도하기를 원하지 않는다고 결정하는 것의 결과일 수 있다. 또는, 이러한 결정은, 애플리케이션 특정 이유와 같은 다른 인자들에 기반할 수 있다.
도 18의 단계(4)에서, DSLT-TF(1202)는, DSLT-MF(1204)에 의해 자신에게 반환되는 DSLT 시퀀스 결과들을 확인한다.
도 18의 단계(5a)에서, DSLT 시퀀스는 DSLT-MF(1204)에 의해 성공적으로 처리되었다. DSLT-TF(1202)는 DSLT 시퀀스가 완료된 것으로 간주할 수 있다.
도 18의 단계(5b)에서, DSLT 시퀀스는 성공적으로 처리되지 않았다. DSLT-TF(1202)는, DSLT-SEQ-TRIGGER 요청을 DSLT-MF(1204)에 재송출하여 DSLT-MF(1204)가 DSLT의 처리를 다시 재시도하게 함으로써 DSLT 시퀀스를 재시도하기로 결정한다.
도 18의 단계(5c)에서, DSLT 시퀀스는 성공적으로 처리되지 않았다. 재시도하기 보다는, DSLT-TF(1202)는 DSLT 시퀀스 요청을 중단하기로 결정한다.
도 18의 단계(6)에서, DSLT 시퀀스는 성공적으로 처리되었고, DSLT-TF(1202)는 DSLT 시퀀스 촉발 요청을 호출한 엔티티(예컨대, 애플리케이션)에 결과들을 반환한다.
도 18의 단계(7)에서, DLST-TF(1202)는 DSLT 시퀀스를 중단하기로 결정한다. DSLT-TF(1202)가 DSLT-MF(1204)로부터 응답을 수신했는지 아니지의 여부에 따라, DSLT-TF(1202)는, 자신이 DSLT 시퀀스를 중단하기로 결정했음을 DSLT-MF(1204)에 통지하기 위해 DSLT-MF(1204)에 중단 요청을 전송하기로 결정할 수 있다.
도 19는, DSLT 시퀀스에 대한 DSLT-MF(1204) 처리를 도시한다.
도 19의 단계(1)에서, DSLT-TF(1202)를 호스팅하는 SL 엔티티는, DSLT 시퀀스를 개시하기 위해, DSLT-MF(1204)를 호스팅하는 SL 엔티티에 DSLT-SEQ-TRIGGER 요청을 전송한다.
도 19의 단계(2)에서, DSLT-MF(1204)는 요청을 처리하고, DSLT-TRIGGER에 의해 표적화된 DSLT-CF들(1208 및 1210) 각각에 시퀀스 내의 제1 DSLT에 대응하는 DSLT-REQ를 배포한다. DSLT-MF(1204)는, DSLT-CF들(1208 및 1210) 각각으로부터, 그들이 표적화된 리소스들에 대한 잠금들을 성공적으로 획득했음을 표시하는 응답들을 대기한다.
도 19의 단계(3a)에서, DSLT-MF(1204)는 DSLT-CF들(1208 및 1210) 전부(또는 정의된 완료 기준들에 따라 하위 세트)가 표적화된 리소스들에 대한 잠금들을 성공적으로 획득할 수 있었음을 검출한다.
도 19의 단계(3b)에서, DSLT-MF(1204)가 하나 이상의 DSLT-CF(1208 및 1210)로부터의 응답들을 대기하면서 타임아웃된다. DSLT-MF(1204)는 시퀀스 내의 제1 DSLT에 대응하는 DSLT-REQ를 타임아웃된 하나 이상의 DSLT-CF에 재전송함으로써 DSLT를 재시도한다.
도 19의 단계(3c)에서, DSLT-MF(1204)는, 시퀀스 완료 기준들에 따라, 시퀀스 내의 제1 DSLT 요청을 그리고 잠재적으로는 전체 DSLT 시퀀스를 중단하기로 결정한다. 이러한 결정은, DSLT-MF(1204)가 타임아웃 이후에 재시도하기를 원하지 않는다고(예컨대, 최대 재시도 횟수에 도달했다고) 결정하는 것의 결과일 수 있다. DSLT-MF(1204)가 하나 이상의 DSLT-CF가 표적화된 리소스(들)에 대한 잠금들을 성공적으로 획득할 수 없었다는 것을 검출하는 경우, DSLT-MF(1204)는, DSLT가 모든 표적화된 DSLT-CF들(1208 및 1210)에 걸쳐 원자적으로 수행될 수는 없으므로 (정의된 완료 기준들에 따라) DSLT를 중단하기로 선택할 수 있다. DSLT-MF(1204)는 각각의 DSLT-CF(1208 및 1210)에 실행 명령을 전송하지 않기로 선택하고 DSLT가 타임아웃되게 놓아둠으로써 DSLT를 중단할 수 있거나, DSLT-MF(1204)는 각각의 DSLT-CF(1208 및 1210)에 중단 명령을 명시적으로 전송할 수 있다. 중단 결정은 또한, 하나 이상의 DSLT-CF가 도달가능하지 않다는 것과 같은 다른 인자들에 기반할 수 있다.
도 19의 단계(4)에서, DSLT-MF(1204)는, 실행 명령을 DSLT-CF들(1208 및 1210)에 전송함으로써, 시퀀스 내의 제1 DSLT에 의해 특정된 동작을 실행할 것을 DSLT-CF들(1208 및 1210)에 지시한다. DSLT-MF(1204)는, DSLT-CF들(1208 및 1210) 각각으로부터, 그들이 표적화된 리소스들 상에서 동작들을 성공적으로 실행했음을 표시하는 응답들을 대기한다.
도 19의 단계(5a)에서, DSLT-MF(1204)는 DSLT-CF들(1208 및 1210) 전부(또는 정의된 완료 기준들에 따라 하위 세트)가 표적화된 리소스들 상에서 DSLT에 의해 특정된 동작들을 성공적으로 실행할 수 있었음을 검출한다.
도 19의 단계(5b)에서, DSLT-MF(1204)가 하나 이상의 DSLT-CF(1208 및 1210)로부터의 응답들을 대기하면서 타임아웃된다. DSLT-MF(1204)는 실행 명령을 타임아웃된 하나 이상의 DSLT-CF에 전송하는 것을 재시도한다.
도 19의 단계(5c)에서, DSLT-MF(1204)는, 시퀀스 완료 기준들에 따라, 시퀀스 내의 제1 DSLT 요청을 그리고 잠재적으로는 전체 DSLT 시퀀스를 중단하기로 결정한다. 이러한 결정은, DSLT-MF(1204)가 타임아웃 이후에 재시도하기를 원하지 않는다고(예컨대, 최대 재시도 횟수에 도달했다고) 결정하는 것의 결과일 수 있다. 또는, 이러한 결정은, 하나 이상의 DSLT-CF(1208 및 1210)가 도달가능하지 않다는 것과 같은 다른 인자들에 기반할 수 있다. DSLT-MF(1204)가 하나 이상의 DSLT-CF가 표적화된 리소스(들) 상에서 동작들을 성공적으로 실행할 수 없었다는 것을 검출하는 경우, DSLT-MF(1204)는, DSLT가 모든 표적화된 DSLT-CF들(1208 및 1210)에 걸쳐 원자적으로 수행될 수는 없으므로 (정의된 완료 기준들에 따라) DSLT를 중단하기로 선택할 수 있다. DSLT-MF(1204)는 각각의 DSLT-CF(1208 및 1210)에 실행 명령을 전송하지 않기로 선택하고 DSLT가 타임아웃되게 놓아둠으로써 DSLT를 중단할 수 있거나, DSLT-MF(1204)는 각각의 DSLT-CF(1208 및 1210)에 중단 명령을 명시적으로 전송할 수 있다.
도 19의 단계(6)에서, 단계(2)에서 정의된 것과 동일한 거동이 제2 DSLT의 처리에 적용될 수 있다.
도 19의 단계(7a)에서, 단계(3a)에서 정의된 것과 동일한 거동이 제2 DSLT의 처리에 적용될 수 있다.
도 19의 단계(7b)에서, 단계(3b)에서 정의된 것과 동일한 거동이 제2 DSLT의 처리에 적용될 수 있다.
도 19의 단계(7c)에서, 단계(3c)에서 정의된 것과 동일한 거동이 제2 DSLT의 처리에 적용될 수 있다.
도 19의 단계(8)에서, 단계(4)에서 정의된 것과 동일한 거동이 제2 DSLT의 처리에 적용될 수 있다.
도 19의 단계(9a)에서, 단계(5a)에서 정의된 것과 동일한 거동이 제2 DSLT의 처리에 적용될 수 있다.
도 19의 단계(9b)에서, 단계(5b)에서 정의된 것과 동일한 거동이 제2 DSLT의 처리에 적용될 수 있다.
도 19의 단계(9c)에서, 단계(5c)에서 정의된 것과 동일한 거동이 제2 DSLT의 처리에 적용될 수 있다.
도 19의 단계(10)에서, 단계(2)에서 정의된 것과 동일한 거동이 제N DSLT의 처리에 적용될 수 있다.
도 19의 단계(11a)에서, 단계(3a)에서 정의된 것과 동일한 거동이 제N DSLT의 처리에 적용될 수 있다.
도 19의 단계(11b)에서, 단계(3b)에서 정의된 것과 동일한 거동이 제N DSLT의 처리에 적용될 수 있다.
도 19의 단계(11c)에서, 단계(3c)에서 정의된 것과 동일한 거동이 제N DSLT의 처리에 적용될 수 있다.
도 19의 단계(12)에서, 단계(4)에서 정의된 것과 동일한 거동이 제N DSLT의 처리에 적용될 수 있다.
도 19의 단계(13a)에서, 단계(5a)에서 정의된 것과 동일한 거동이 제N DSLT의 처리에 적용될 수 있다.
도 19의 단계(13b)에서, 단계(5b)에서 정의된 것과 동일한 거동이 제N DSLT의 처리에 적용될 수 있다.
도 19의 단계(13c)에서, 단계(5c)에서 정의된 것과 동일한 거동이 제N DSLT의 처리에 적용될 수 있다.
도 19의 단계(14)에서, DSLT-MF(1204)가, DSLT-CF들(1208 및 1210) 전부(또는 정의된 시퀀스 완료 기준들에 따라 하위 세트)가 DSLT들의 전체 시퀀스에 의해 특정된 바와 같은 모든 표적화된 리소스들 상에서 모든 동작들을 성공적으로 실행할 수 있었음을 검출하는 경우, DSLT-MF(1204)는, 결과들의 상태가 지속적으로 유지되도록 시퀀스 내의 모든 적용가능한 DSLT들을 커밋할 것을 DSLT-CF들(1208 및 1210) 각각에 지시한다.
도 19의 단계(15a)에서, DSLT-MF(1204)는 DSLT-CF들(1208 및 1210) 전부(또는 정의된 완료 기준들에 따라 하위 세트)가 표적화된 리소스들 상에서 DSLT에 의해 특정된 동작들의 결과들을 성공적으로 커밋할 수 있었음을 검출한다.
도 19의 단계(15b)에서, DSLT-MF(1204)가 하나 이상의 DSLT-CF로부터의 응답들을 대기하면서 타임아웃된다. DSLT-MF(1204)는 커밋 명령을 타임아웃된 하나 이상의 DSLT-CF에 전송하는 것을 재시도한다.
도 19의 단계(15c)에서, DSLT-MF(1204)는 시퀀스 완료 기준들에 기반하여 DSLT 시퀀스를 중단하기로 결정한다. 이러한 결정은, DSLT-MF(1204)가 타임아웃 이후에 재시도하기를 원하지 않는다고(예컨대, 최대 재시도 횟수에 도달했다고) 결정하는 것의 결과일 수 있다. 또는, 이러한 결정은, 하나 이상의 DSLT-CF가 도달가능하지 않다는 것과 같은 다른 인자들에 기반할 수 있다. DSLT-MF(1204)가 하나 이상의 DSLT-CF가 표적화된 리소스(들) 상에서 동작들을 성공적으로 커밋할 수 없었다는 것을 검출하는 경우, DSLT-MF(1204)는, DSLT 시퀀스가 모든 표적화된 DSLT-CF들(1208 및 1210)에 걸쳐 원자적으로 수행될 수는 없으므로 (정의된 완료 기준들에 따라) DSLT 시퀀스를 중단하기로 선택할 수 있다. DSLT-MF(1204)는, DSLT 시퀀스를 촉발한 DSLT-TF(1202)에 오류를 반환함으로써 DSLT 시퀀스를 중단할 수 있다.
도 19의 단계(16)에서, DSLT 시퀀스는 성공적으로 처리되었고, DSLT-MF(1204)는 DSLT 시퀀스를 촉발한 DSLT-TF(1202)에 결과들을 반환한다.
도 19의 단계(17)에서, DLST-MF는 DSLT 시퀀스를 중단하기로 결정한다. DSLT-MF(1204)가 DSLT-CF들(1208 및 1210)로부터 응답을 수신했는지 아닌지 여부에 따라, DSLT-MF(1204)는 자신이 시퀀스 내의 하나 이상의 DSLT를 중단하기로 결정했음을 하나 이상의 DSLT-CF(1208 및 1210)에 통지하기 위해 하나 이상의 DSLT-CF(1208 및 1210)에 명시적 중단 요청을 전송하기로 결정할 수 있으며, 따라서, 하나 이상의 DSLT-CF(1208 및 1210)는, DSLT 시퀀스의 처리를 중단하는 것, 표적화된 리소스의 상태를 그의 원래의 상태로 롤백하는 것, 또는 표적화된 리소스를 잠금해제하는 것과 같은 임의의 필요한 처리를 수행할 수 있다.
도 20은, DSLT 시퀀스에 대한 DSLT-CF 처리를 도시한다.
도 20의 단계(1)에서, DSLT-CF(1210)를 호스팅하는 SL 엔티티는, 시퀀스 내의 제1 DSLT에 대응하는 DSLT-MF(1204)로부터 DSLT-REQ를 수신한다. 대안적으로, 각각의 DSLT-CF(1208 및 1210)가 단일 요청으로 함께 배칭된 시퀀스 내의 모든 DSLT들을 수신할 수 있다.
도 20의 단계(2)에서, DSLT-CF(1210)는 DSLT-REQ를 처리하고, 트랜잭션이 격리되어 수행되고 임의의 다른 DSLT-REQ들에 의해 간섭받지 않음을 보장하기 위해 DSLT-REQ에 의해 표적화된 리소스(들)를 (요구되는 경우) 잠그려 시도한다. DSLT-CF(1210)는 (요구되는 경우) 잠금이 획득될 때까지 이러한 상태에서 대기한다. DSLT-CF(1210)는, 동일한 시퀀스 내의 DSLT들이 리소스(들) 상에서 동작하는 것을 허용하지만 임의의 다른 DSLT들에 대해서는 허용하지 않도록 이러한 잠금을 DSLT 시퀀스와 연관시킬 수 있다. 이러한 잠금은 동작 유형에 따라 조건부로 이루어질 수 있다. 예컨대, 동작이 업데이트 또는 삭제인 경우에만 표적화된 리소스를 잠근다. 그러나, 일부 사용 경우들에서, 검색을 수행하기 위한 DSLT-REQ가 실행되기 전에 다른 DSLT-REQ가 리소스를 수정하거나 삭제하지 않음을 보장하기 위해 검색에 대한 잠금이 또한 타당할 수 있다. 일단 하나의 DSLT-REQ에 의해 리소스가 잠기면, 이러한 잠금이 사용되어, 다른 DSLT-REQ들이 리소스에 액세스하는 것을 차단할 수 있다. 이러한 차단은, 심지어 잠금된 리소스의 상태가 커밋되고 잠금해제될 때까지 잠금된 리소스의 검색이 차단될 필요가 있을 수 있으므로, 다른 DSLT-REQ들로부터의 모든 동작들에 적용가능해질 수 있다.
도 20의 단계(3a)에서, DSLT-CF(1210)는 DSLT-REQ에 의해 표적화된 리소스(들)에 대한 잠금을 (요구되는 경우) 성공적으로 획득할 수 있다. 이러한 차단은, 심지어 잠금된 리소스의 상태가 커밋되고 잠금해제될 때까지 잠금된 리소스의 검색이 차단될 필요가 있을 수 있으므로, 다른 DSLT-REQ들로부터의 모든 동작들에 적용가능해질 수 있다.
도 20의 단계(3b)에서, DSLT-CF(1210)는 타임아웃 기간이 경과하기 전에는 표적화된 리소스에 대한 잠금을 획득할 수 없으며, 그러므로, DSLT-CF(1210)는 DSLT-REQ를 타임아웃하고 중단하기로 선택한다. DSLT-CF(1210)는 이러한 타임아웃을 DSLT-MF(1204)에 통지할 수 있다. 타임아웃에 후속하여, DSLT-CF는 DSLT-MF(1204)로부터 재시도된 DSLT-REQ를 수신할 수 있으며, 이러한 경우에, DSLT-CF는 단계(1)로 시작하는 흐름을 반복할 수 있다.
도 20의 단계(3c)에서, DSLT-CF(1210)는 DSLT-MF(1204)로부터 명시적 중단 명령을 수신하며, 그러므로, DSLT-CF(1210)는 DSLT-REQ를 중단한다. DSLT-CF(1210)가 표적화된 리소스들 중 임의의 리소스에 대해 잠금들을 획득할 수 있었던 경우, DSLT-CF(1210)는 이러한 잠금들을 해제하고 DSLT의 처리를 중단한다. DSLT-CF(1210)는 DSLT-MF(1204)로부터 재시도된 DSLT-REQ를 수신할 수 있으며, 이러한 경우에, DSLT-CF(1210)는 단계(1)로 시작하는 흐름을 반복할 수 있다.
도 20의 단계(4)에서, 표적화된 리소스(들)에 대한 잠금이 (요구되는 경우) 각각의 DSLT-CF(1208 및 1210)에 의해 획득된다. 각각의 DSLT-CF는, 잠금이 획득되었다는 것 또는 요구되지 않는다는 것을 DSLT-MF(1204)에 통지한다. DSLT-CF는, 표적화된 리소스(들) 상에서 DSLT 특정된 동작(들)을 실행하기 위한 DSLT-MF(1204)로부터의 명령을 수신할 때까지 이러한 상태에서 대기한다.
도 20의 단계(5a)에서, DSLT-CF(1210)는 DSLT-MF(1204)로부터 실행 명령을 수신했으며, 표적화된 리소스(들) 상에서 DSLT 특정된 동작(들)의 실행을 성공적으로 완료할 수 있었다.
도 20의 단계(5b)에서, DSLT-CF(1210)는 타임아웃 기간이 경과하기 전에는 DSLT-MF(1204)로부터 실행 명령을 수신하지 않으며, 그러므로, DSLT-CF(1210)는 DSLT-REQ를 타임아웃하고 리소스를 잠금해제한다. DSLT-CF(1210)는 이러한 타임아웃을 DSLT-MF(1204)에 통지할 수 있다. 타임아웃에 후속하여, DSLT-CF(1210)는 DSLT-MF(1204)로부터 DSLT-REQ 명령을 수신할 수 있다.
도 20의 단계(5c)에서, DSLT-CF(1210)는 DSLT-REQ의 실행을 중단한다. 이는, DSLT-MF(1204)로부터 실행 명령을 수신하고 표적화된 리소스(들) 상에서 DSLT 특정된 동작(들)을 성공적으로 실행할 수 없는 것의 결과일 수 있다. 대안적으로, 이는, DSLT-CF(1210)가 DSLT-MF(1204)로부터 중단 명령을 수신하는 것의 결과일 수 있다.
도 20의 단계(6)에서, DSLT-CF(1210)는 실행을 성공적으로 완료했다. DSLT-CF(1210)는 자신의 실행 상태를 DSLT-MF(1204)에 통지하고, 시퀀스 내의 다음 DSLT 또는 DSLT-MF(1204)로부터의 커밋 명령을 대기한다. 시퀀스에서 다음 DSLT가 수신되는 경우, 단계(2)에서 정의된 것과 동일한 거동이 이러한 다음 DSLT의 처리에 적용될 수 있다.
도 20의 단계(7a)에서, 단계(3a)에서 정의된 것과 동일한 거동이 제2 DSLT의 처리에 적용될 수 있다.
도 20의 단계(7b)에서, 단계(3b)에서 정의된 것과 동일한 거동이 제2 DSLT의 처리에 적용될 수 있다.
도 20의 단계(7c)에서, 단계(3c)에서 정의된 것과 동일한 거동이 제2 DSLT의 처리에 적용될 수 있다.
도 20의 단계(8)에서, 단계(4)에서 정의된 것과 동일한 거동이 제2 DSLT의 처리에 적용될 수 있다.
도 20의 단계(9a)에서, 단계(5a)에서 정의된 것과 동일한 거동이 제2 DSLT의 처리에 적용될 수 있다.
도 20의 단계(9b)에서, 단계(5b)에서 정의된 것과 동일한 거동이 제2 DSLT의 처리에 적용될 수 있다.
도 20의 단계(9c)에서, 단계(5c)에서 정의된 것과 동일한 거동이 제2 DSLT의 처리에 적용될 수 있다.
도 20의 단계(10)에서, 단계(6)에서 정의된 것과 동일한 거동이 제N DSLT의 처리에 적용될 수 있다.
도 20의 단계(11a)에서, 단계(3a)에서 정의된 것과 동일한 거동이 제N DSLT의 처리에 적용될 수 있다.
도 20의 단계(11b)에서, 단계(3b)에서 정의된 것과 동일한 거동이 제N DSLT의 처리에 적용될 수 있다.
도 20의 단계(11c)에서, 단계(3c)에서 정의된 것과 동일한 거동이 제N DSLT의 처리에 적용될 수 있다.
도 20의 단계(12)에서, 단계(4)에서 정의된 것과 동일한 거동이 제N DSLT의 처리에 적용될 수 있다.
도 20의 단계(13a)에서, 단계(5a)에서 정의된 것과 동일한 거동이 제N DSLT의 처리에 적용될 수 있다.
도 20의 단계(13b)에서, 단계(5b)에서 정의된 것과 동일한 거동이 제N DSLT의 처리에 적용될 수 있다.
도 20의 단계(13c)에서, 단계(5c)에서 정의된 것과 동일한 거동이 제N DSLT의 처리에 적용될 수 있다.
도 20의 단계(14)에서, DSLT-CF(1210)는 시퀀스 내의 제N DSLT의 실행을 성공적으로 완료한다. DSLT-CF(1210)는 자신의 실행 상태를 DSLT-MF(1204)에 통지하고, 시퀀스 내의 다음 DSLT 또는 DSLT-MF(1204)로부터의 커밋 명령을 대기한다.
도 20의 단계(15a)에서, DSLT-CF(1210)는 시퀀스 내의 DSLT들을 성공적으로 커밋할 수 있었다.
도 20의 단계(15b)에서, DSLT-CF(1210)는 타임아웃 기간이 경과하기 전에는 시퀀스 내의 후속 DSLT 또는 DSLT-MF(1204)로부터의 커밋 명령을 수신하지 않으며, 그러므로, DSLT-CF(1210)는 DSLT 시퀀스를 타임아웃한다. 이것이 발생하는 경우/발생할 때, DSLT-CF는 시퀀스 내의 업데이트된 리소스(들)의 상태를 커밋하지 않으며, 대신, 시퀀스 내의 DSLT 동작들 중 임의의 것이 수행되기 전에 표적화된 리소스(들)의 상태가 초기 상태로 롤백되도록 중단한다. 유사하게, 표적화된 리소스(들) 상에서 DSLT 특정된 동작을 실행한 후에, DSLT-CF(1210)가 DSLT-MF(1204)로부터 명시적 중단 명령을 수신하는 경우, DSLT-CF(1210)는, 업데이트된 리소스(들)의 상태를 커밋하지 않고 대신 그것을 중단함으로써 DSLT 시퀀스를 중단할 수 있으며, 따라서, 표적화된 리소스(들)의 상태는, 시퀀스 내의 DSLT 동작들 중 임의의 동작이 수행되기 전에 초기 상태로 롤백된다. DSLT-CF(1210)는 이러한 중단을 DSLT-MF(1204)에 통지할 수 있다.
도 20의 단계(15c)에서, DSLT-CF(1210)는, 시퀀스의 일부로서 처리되고 아직 커밋되지 않은 모든 DSLT들의 커밋을 중단한다. 이는, DSLT-MF(1204)로부터 커밋 명령을 수신하고 결과들을 성공적으로 커밋할 수 없는 것의 결과일 수 있다. 대안적으로, 이는, DSLT-CF(1210)가 DSLT-MF(1204)로부터 중단 명령을 수신하는 것의 결과일 수 있다.
도 20의 단계(16)에서, 커밋에 후속하여, DSLT-CF(1210)는 시퀀스 내의 DSLT들 중 임의의 DSLT에 의해 표적화된 리소스(들)에 대한 잠금을 해제할 수 있다. 이러한 경우에서, DSLT-CF는 또한 DSLT-MF(1204)에 커밋들의 통지를 전송할 수 있다.
도 20의 단계(17)에서, 타임아웃 또는 중단이 발생하는 경우, DSLT-CF는 시퀀스의 일부로서 처리된 모든 DSLT들을 중단 및 롤백하고, 대응하는 상태를 DSLT-MF(1204)에 반환할 수 있다. 중단에 후속하여, DSLT-CF(1210)는 또한 리소스들에 대한 잠금들을 해제해야 한다. 이러한 경우에서, DSLT-CF(1210)는 또한 DSLT-MF(1204)에 중단의 통지를 전송할 수 있다.
DSLT-MF 정책 엔진 능력
DSLT-MF(1204)는 DSLT 정책 엔진 능력(1308)을 지원할 수 있다. 자신의 API를 통해, DSLT-MF(1204)는 DSLT 처리 정책들을 생성, 검색, 업데이트, 또는 삭제하기 위한 정책 구성 요청들을 지원할 수 있다. 이러한 정책들은, DSLT-MF(1204)가 DSLT들을 처리하는 방식 및 표적화된 DSLT-CF들(1208 및 1210)과의 그의 상호작용을 제어하는 DSLT-MF(1204) 내의 DSLT 처리 규칙들을 구성하는 데 사용될 수 있다.
다음의 유형들의 DSLT 처리 정책들이 사용될 수 있다:
- DSLT 스케줄링 정책들 ― 이러한 정책들은, DSLT-MF(1204)가 DSLT들 또는 DSLT 시퀀스들의 처리를 스케줄링하는 방식을 제어하는 규칙들을 구성하는 데 사용될 수 있다.
- DSLT 재시도 정책들 ― 이러한 정책들은, DSLT-MF(1204)가 처리를 실패한 DSLT 또는 DSLT 시퀀스를 재시도하는지를 그리고 재시도하는 때를 제어하는 규칙들을 구성하는 데 사용될 수 있다. 규칙들은 DSLT가 할 수 있는 횟수에 대한 최대 또는 최소 재시도 제한들을 포함할 수 있다.
- DSLT 우선순위화 정책들 ― 이러한 정책들은, DSLT-MF(1204)가 DSLT 또는 DSLT 시퀀스들의 처리를 서로에 대해 우선순위화하고 순위화하는 방식을 제어하는 규칙들을 구성하는 데 사용될 수 있다.
- DSLT 실행 기준 정책들 ― 이러한 정책들은, DSLT-MF(1204)가 DSLT들 또는 DSLT 시퀀스들에 대한 실행 기준들을 배정하고 처리하는 방식을 제어하는 규칙들을 구성하는 데 사용될 수 있다.
- DSLT 완료 기준 정책들 ― 이러한 정책들은, DSLT-MF(1204)가 DSLT들 또는 DSLT 시퀀스들에 대한 완료 기준들을 배정하고 처리하는 방식을 제어하는 규칙들을 구성하는 데 사용될 수 있다.
위의 유형들의 정책들 각각의 적용가능성/범위가 구성될 수 있다. 예컨대, 정책의 범위는 다음으로 제한될 수 있다:
- 특정 소스(예컨대, 특정 DSLT-TF(1202) 또는 DSLT-TF(1202)들의 그룹)로부터 발신된 DSLT
- 특정 표적(예컨대, 특정 DSLT-CF 또는 DSLT-CF들의 그룹)을 향해 표적화된 DSLT
- 특정 유형의 DSLT(예컨대, 동작이 생성과 동일한 DSLT)
다음의 유형들의 정책 엔진 기능성이 사용될 수 있다. DSLT-MF(1204)는, 대응하는 정책 규칙들(예컨대, 스케줄링, 재시도, 우선순위화, 및 완료 기준 규칙들)을 자신이 수신한 착신 DSLT 요청들에 적용할 수 있다. 이러한 규칙들은, 이러한 파라미터들에 대한 자신 고유의 대응하는 값들을 명시적으로 정의하지 않는 DSLT 요청들(예컨대, 이들은, 이러한 값들을 명시적으로 설정하기 위한 DSLT 메시지 파라미터들을 포함하지 않음)에 적용될 수 있는 기본들로서 사용될 수 있다. DSLT 요청이 이러한 파라미터들 중 하나 이상에 대한 명시적 값들을 포함하지 않는 경우에서, 이러한 정책들은 제한들로서 사용될 수 있다. DSLT-MF(1204)는 이러한 정책 제한들을 DSLT 요청에서 명시적으로 정의된 파라미터에 대해 비교할 수 있고, 필요한 경우, 제한들을 준수하도록 명시적 값들을 변경함으로써 이러한 제한들을 강제할 수 있다.
리소스 예비를 위한 DSLT-MF 스케줄링 능력
DSLT-MF(1204)는 중앙집중형 DSLT 스케줄링 기능(1310)의 역할을 할 수 있다. 그러한 기능은, SL 엔티티들의 분산된 세트, 및 DSLT들을 실행하기 위해 필요한 이러한 엔티티들에 의해 호스팅되는 리소스들에 대한 액세스를 스케줄링하는 능력을 지원할 수 있다. 이러한 스케줄링을 미리 사전대응적으로 행함으로써, 이는, 주어진 DSLT를 실행하는 데 요구되는 리소스들이 필요할 때 이용가능하고 이러한 리소스들에 대한 경합이 최소화됨을 보장하는 것을 도울 수 있다. 이는, 첫 번째 시도에서의 성공적인 DSLT 처리 가능성이 증가되는 것을 초래할 수 있고, 이는 성능을 개선할 수 있다(예컨대, 재시도 시도들의 발생을 감소시킬 수 있음). 중앙집중형 DSLT-MF 스케줄링 능력은, DSLT들 각각에서 특정된 표적화된 리소스(들) 및 대응하는 동작(들)을 조사할 수 있다. 모든 DSLT들에 걸친 이러한 종합 정보 세트에 기반하여, 이어서, DSLT-MF(1204)는 정보에 근거한 DSLT 스케줄링 결정들을 행할 수 있고, 모든 미해결 DSLT들의 상위 세트에 걸쳐 표적화된 리소스들에 대한 액세스를 최적화할 수 있다.
다음의 DSLT 스케줄링 기능성(1310)이 사용될 수 있다.
1) DSLT-MF(1204)는, DSLT들의 표적들인 IoT 디바이스들의 도달가능성 스케줄들을, DSLT가 자신의 표적화된 디바이스들 전부에 대해 성공적으로 수행될 수 있고 DSLT의 원자적 실행 요건들을 충족할 수 있게, 모든 요구되는 디바이스들이 온라인이고 이용가능함을 보장하는 것을 돕도록 조정할 수 있다. 이는, 디바이스들 중 하나가 이용가능하지 않은 경우, 원자성의 결여로 인해 DSLT가 실패하는 것을 초래할 것이므로 중요하다. DSLT-MF(1204)는, 표적화된 디바이스들 각각의 연결성 스케줄들을 DSLT 요청이 그들에게 송출되기 전에 서로 정렬되도록 구성하기 위해, 표적화된 디바이스들 각각과 조정할 수 있다. 이러한 정렬은, 1회성/애드-혹 기반으로 이루어질 수 있거나, 또한, 사실상 반복적인 DSLT들의 그 유형들에 대해 재발생/상설(standing) 기반으로 이루어질 수 있다.
2) DSLT-MF(1204)는, 동일한 리소스(들)를 표적화하는 다수의 DSLT들 또는 DSLT 시퀀스들이, 이들 각각이 자신의 대응하는 트랜잭션들이 격리되어 수행되고 간섭받지 않음을 보장하기 위해서는 자신의 표적 리소스(들)에 대한 잠금을 획득해야 하므로, 동시에 실행되지 않음을 보장할 수 있다. 동일한 리소스(들)를 표적화하는 DSLT들을 동시에 실행하려고 시도하는 것은, 비-최적 DSLT 실행(예컨대, 지연들, 타임아웃들, 재시도들 등) 또는 심지어 DSLT들의 실패들을 초래할 수 있다. DSLT-MF(1204)는 각각의 DSLT 및 그의 구성된 표적(들)을 조사할 수 있다. 그런 다음, DSLT-MF(1204)는, DSLT들의 실행을, 겹치는 표적들을 갖는 그 DSLT들이 동시에 실행되지 않는 한편 겹치는 표적들이 없는 DSLT들은 겹쳐질 수 있음을 보장하도록 서로에 대해 적절하게 스케줄링 및 시퀀싱할 수 있다. DSLT-MF(1204)는 또한, 각각의 DSLT 내에 구성된 우선순위를 고려할 수 있고, 이를 자신의 스케줄링 알고리즘에 포함시켜 더 높은 우선순위의 DSLT들이 더 낮은 우선순위의 DSLT들 전에 실행될 수 있게 할 수 있다.
DSLT 절차들
다음의 절차들은 성공적인 DSLT 처리 시나리오들을 설명한다.
개별 DSLT 절차
도 21은 개별 DSLT 절차를 예시한다.
도 21의 단계(1)는 임의적 단계이다. 도 21의 단계(1)에서, IoT 애플리케이션의 DSLT-TF(1202)는 DSLT 정책 리소스들을 생성하기 위한 요청(들)을 IoT 서버의 DSLT-MF(1204)에 전송한다. 각각의 정책 리소스는 DSLT-MF(1204)가 DSLT 요청들을 처리하는 방식을 제어하기 위한 하나 이상의 규칙을 포함할 수 있다. 이러한 규칙들은, DSLT 스케줄링, DSLT들의 재시도, DSLT들의 우선순위화, DSLT들에 대한 실행 및 완료 기준들에 관한 것일 수 있다. 대안적으로, IoT 서버의 DSLT-MF(1204)에는 DSLT 정책들이 사전 프로비저닝될 수 있다.
도 21의 단계(2)는 임의적 단계이다. 도 21의 단계(2)에서, IoT 서버의 DSLT-MF(1204)는 DSLT 정책 리소스들을 생성하기 위한 요청을 수신하여 처리한다. DSLT-MF(1204)는 정책 리소스를 생성하고, 또한, 정책들에서 특정된 규칙들로 자신의 DSLT 정책 엔진(1308)을 구성한다.
도 21의 단계(3)는 임의적 단계이다. 도 21의 단계(3)에서, IoT 서버의 DSLT-MF(1204)는, 정책 리소스들에서 정의된 규칙들이 수락되었는지 아닌지 여부를 IoT 애플리케이션의 DSLT-TF(1202)에 알리기 위해 그 DSLT-TF(1202)에 응답을 반환한다. 그렇지 않은 경우, DSLT-MF(1204)는 DSLT-MF(1204)에 의해 수락되었던 규칙들의 수정된 버전을 제공할 수 있다.
도 21의 단계(4)에서, IoT 애플리케이션의 DSLT-TF(1202)는 DSLT-TRIGGER 요청을 IoT 서버의 DSLT-MF(1204)에 전송한다. 요청은, 표적화된 노드들(예컨대, IoT 디바이스 1 및 IoT 디바이스 2)의 세트, 이러한 노드들 상에서 수행할 동작, 동작을 수행할 때의 스케줄, 실행 기준들의 세트, 우선순위, 트랜잭션을 처리하려는 시도들이 실패한 경우에서의 재시도 횟수, 완료 기준들의 세트, DSLT 식별자, 및 DSLT-MF(1204)가 비-차단 방식으로 트랜잭션을 처리하는 데 사용할 수 있는 접촉 정보와 같은 몇몇 파라미터들을 포함할 수 있다.
도 21의 단계(5)에서, IoT 서버의 DSLT-MF(1204)는 DSLT-TRIGGER 요청을 수신하여 처리하기 시작한다. DSLT-MF(1204)는, DSLT를 처리하는 동안 상태를 계속 추적하기 위해 DSLT 요청 리소스를 생성한다. DSLT-MF(1204)는, 단계(4)에서 설명된 DSLT-TRIGGER 요청 파라미터들에 포함된 정보로 리소스의 속성들을 구성한다.
도 21의 단계(6)에서, IoT 서버의 DSLT-MF(1204)는, 자신이 요청을 수신했고 그 요청을 처리하기 시작했다는 것을 표시하는 응답을 IoT 애플리케이션의 DSLT-TF(1202)에 반환함으로써 비-차단 방식으로 DSLT-TRIGGER 요청을 처리한다. 대안적으로, DSLT-MF(1204)는 이러한 요청을 차단 방식으로 처리할 수 있다.
도 21의 단계(7)에서, IoT 서버의 DSLT-MF(1204)는 표적화된 리소스들의 목록을 발견하기 위해 DSLT-TRIGGER 요청을 파싱한다. DSLT-MF(1204)는, 표적화된 리소스들이 IoT 서버 상에서 국부적으로 호스팅되지 않고 오히려 IoT 디바이스들 1 및 2에 의해 호스팅됨을 검출한다. 그러므로, DSLT-MF(1204)는 이러한 표적화된 디바이스들을 배포하기 위해 대응하는 DSLT-REQ들을 준비한다. 요청들을 배포하기 전에, DSLT-CF(1210)는 먼저, DSLT-TRIGGER 요청 또는 임의의 DSLT 스케줄 관련 정책들에 임의의 스케줄 정보가 명시적으로 구성되었는지를 확인한다. DSLT-MF(1204)는 또한, DSLT-TRIGGER 요청 또는 임의의 DSLT 스케줄 정책들에 임의의 우선순위가 명시적으로 구성되었는지를 확인한다. 명시적으로 구성된 경우, DSLT-MF(1204)는, 자신이 수신하고 처리를 요구하는 임의의 다른 DSLT-TRIGGER 요청들이 존재하는지를 확인한다. 존재하는 경우, DSLT-MF(1204)는 우선순위 및 스케줄 정보를 사용하여 DSLT-TRIGGER 요청들의 실행을 서로에 대해 순위화 및 순서화한다. 일단 스케줄 및 우선순위가 그것을 허용하면, DSLT-MF(1204)는 그에 따라 DSLT-REQ들을 표적들에 배포한다. DSLT-MF(1204)의 우선순위화 정책들에 따라, 활성으로 처리되고 있는 DSLT-TRIGGER보다 더 높은 우선순위를 갖는 새로운 DSLT-TRIGGER가 수신되는 경우, DSLT-MF(1204)는, 활성으로 처리되고 있는 DSLT-TRIGGER를 완료하거나, 새로 도착된 더 높은 우선순위의 DSLT-TRIGGER를 처리하기 위해 그를 선점대체(pre-empt)할 수 있다. 선점대체의 경우에서, DSLT-MF(1204)는 나중에 다시 처리를 재시작하기 위하여 트랜잭션을 중단 및 롤백할 수 있거나, DSLT-MF(1204)는 더 높은 우선순위의 트랜잭션을 처리하는 동안 처리를 일시정지하고 그런 다음 나중에 그 처리를 재개할 수 있다. 이러한 중단 대 선점대체 결정은, 몇몇 인자들, 이를테면, 더 높은 우선순위의 트랜잭션이 활성으로 처리되고 있는 더 낮은 우선순위의 트랜잭션과 동일한 리소스들을 표적화하는지 여부에 기반할 수 있다. 이러한 경우에서, DSLT-MF(1204)는 더 낮은 우선순위의 트랜잭션을 중단하기로 결정할 수 있는 반면, 2개의 트랜잭션이 상이한 리소스들을 표적화하는 경우에 대해서는, DSLT-MF(1204)는 더 낮은 우선순위의 트랜잭션을 선점대체하거나 지원되는 경우에는 둘 모두를 병렬로 실행하기로 선택할 수 있다.
도 21의 단계(8)에서, IoT 디바이스(1234 및 1236) 상의 DSLT-CF들(1208 및 1210) 각각이 그들의 DSLT-REQ들을 수신한다. 둘 모두는 요청을 처리하고, 그들이 DSLT-REQ를 처리하는 동안 트랜잭션 상태의 추적을 계속하기 위해 국부적 DSLT 리소스를 생성한다. DSLT-CF들(1208 및 1210)은 그들의 리소스들의 속성들을 DSLT-REQ 파라미터들에 포함된 정보로 구성한다. DSLT-CF들(1208 및 1210)은, 먼저, 표적화된 리소스(들)의 이용가능성을 확인함으로써, 트랜잭션을 처리하는 것을 시작한다. 리소스(들)가 IoT 디바이스에 국부적인 경우, DSLT-CF(1210)는, 리소스의 특정된 동작을 수행하기 위한 이용가능성, 및 현재 리소스를 예비하고 잠근 다른 트랜잭션들이 존재하지 않는다는 것을 확인한다. 리소스가 이용가능한 경우, DSLT-CF(1210)는, 현재 트랜잭션의 처리 동안 도달할 수 있는 다른 트랜잭션들로부터의 간섭 없이 리소스 상에서 자신이 트랜잭션을 수행할 수 있도록 그 리소스를 잠글 수 있다. DSLT-CF(1210)가 DSLT-REQ를 수신하고 요청이 국부적 디바이스 상에서 호스팅되지 않는 리소스를 표적화하는 것을 발견한 경우에서, DSLT-CF는 (가능하게는, 디바이스 상에서 호스팅되는 국부적 DSLT-MF(1204)와 협력하여) 다른 디바이스 상의 DSLT-CF(1210)가 그것을 처리할 수 있도록 시스템 내의 다른 디바이스에 DSLT-REQ 요청을 재표적화할 수 있다.
도 21의 단계(9)에서, 각각의 IoT 디바이스 상의 DSLT-CF(1210)는, DSLT-REQ가 수신되었고, 트랜잭션에 대해 처리가 시작되었고, 표적화된 리소스가 이용가능하고, 다른 트랜잭션들로부터의 간섭 없이 현재 트랜잭션이 진행될 수 있기 위해 리소스가 잠겼음을 표시하는 상태를 IoT 서버의 DSLT-MF(1204)에 반환한다.
도 21의 단계(10)에서, IoT 서버 상의 DSLT-MF(1204)는, 모든 표적화된 DSLT-CF들(1208 및 1210)(즉, IoT 디바이스들 1 및 2 둘 모두)이 그들이 표적화된 리소스들을 성공적으로 잠갔음을 응답하는 것을 검출한다. 결과적으로, DSLT-MF(1204)는, 표적화된 DSLT-CF에 트랜잭션을 실행할 것을 지시하도록 진행할 수 있다고 결정한다. DSLT-MF(1204)가 모든 표적들로부터 성공적인 잠금 응답을 수신하지 못한 경우에서, DSLT-MF(1204)는, 임의의 완료 기준들이 트랜잭션에 대해 구성되거나 그의 정책들 중 임의의 정책에 특정된지 여부를 확인할 수 있다. 완료 기준들이 특정된 경우, DSLT-MF(1204)는, 기준들이 DSLT-MF(1204)가 진행할 수 있게 하는지 또는 아닌지를 확인할 수 있다(예컨대, 기준들은, 모든 표적들 대신 표적들의 하위 세트 상에서만 트랜잭션이 완료되도록 요구된다는 것을 특정할 수 있음). 대안적으로, 트랜잭션들 중 하나 이상이 표적화된 리소스를 잠그는 데 실패하는 경우에서, DSLT-MF(1204)는 트랜잭션이 자신의 구성 파라미터를 통해 또는 정책 설정을 통해 재시도되도록 구성되는지 또는 아닌지 여부를 확인할 수 있다. 재시도들이 허용되는 경우, DSLT-MF(1204)는 실패한 트랜잭션을 재시도할 수 있다. 이러한 경우에서, DSLT-MF(1204)는 실패한 DSLT-CF(들)에 재시도를 전송할 수 있다. DSLT-MF(1204)가, 완료 기준들이 충족될 수 없고 트랜잭션을 재시도할 수 없다고 결정하는 경우에서, DSLT-MF(1204)는 트랜잭션을 중단하기로 선택할 수 있다. 트랜잭션을 중단하기 위해, DSLT-MF(1204)는 트랜잭션 표적들 각각(이러한 예에서는, IoT 디바이스(1234 및 1236) 상의 DSLT-CF들(1208 및 1210))에 중단 명령을 전송한다. 중단을 수신할 시, DSLT-CF는, 트랜잭션에 의해 표적화된 리소스(들)에 대해 이루어진 임의의 수정들을, 그 리소스(들)가 트랜잭션의 시작 전에 있던 상태와 동일한 상태로 복귀되도록 롤백함으로써 트랜잭션을 중단한다. DSLT-CF는 또한 표적화된 리소스(들)에 대한 잠금을 해제할 수 있다.
대안적으로, DSLT-CF(1210)가 단계(8)에서 리소스를 잠글 수 없었던 경우, DSLT-CF(1210)는 리소스가 이용가능하지 않은 이유(리소스가 존재하지 않음, 불충분한 액세스 권한들, 리소스가 이미 잠겨 있음)에 관한 표시를 제공할 수 있다. 리소스가 잠긴 경우, DSLT-CF(1210)는 또한 (잠긴 리소스와 연관된 타임아웃들에 기반하여) 리소스가 잠금해제될 수 있는 시간에 관한 표시를 제공할 수 있다. 그러한 경우에서, DSLT-MF(1204)는 (DSLT-CF(1210)에 의해 제공되는 정보에 기반하여) 얼마간의 나중의 시간에 트랜잭션의 재시도를 시도할 수 있다.
도 21의 단계(11)에서, IoT 서버 상의 DSLT-MF(1204)는, 각각의 표적화된 DSLT-CF(1208 및 1210)에 트랜잭션을 실행할 것을 명령하기 위한 요청을 전송한다. 이러한 명령은, DSLT-MF(1204)가, DSLT-CF(1208 및 1210)에 트랜잭션을 실행할 것을 지시하는 각각의 IoT 디바이스 상에서 호스팅되는 DSLT 리소스 내의 명령 속성을 업데이트하는 것에 의해 송출될 수 있다.
도 21의 단계(12)에서, 트랜잭션을 실행하기 위한 명령을 수신할 시, 각각의 디바이스 상의 DSLT-CF(1210)는 표적화된 리소스 상에서 트랜잭션에 특정된 동작을 수행한다. 표적화된 리소스 상에서의 동작의 결과로서, IoT 디바이스에서의 다수의 리소스들의 상태가 변할 수 있다. DSLT-CF(1210)는, DSLT-REQ가 중단되고 롤백될 필요가 있는 경우, 필요한 경우에는 (동작의 실행 전의) 동작 전 상태의 사본을 유지한다.
도 21의 단계(13)에서, 일단 실행이 완료되면, 각각의 DSLT-CF(1210)는 실행의 결과들 및 그것이 성공적이었는지 여부로 DSLT-MF(1204)에 다시 응답한다.
도 21의 단계(14)에서, IoT 서버 상의 DSLT-MF(1204)는, 모든 표적화된 DSLT-CF들(즉, IoT 디바이스들(1234 및 1236) 둘 모두)이 그들이 표적화된 리소스들 상에서 트랜잭션을 성공적으로 실행했음을 응답하는 것을 검출한다. 결과적으로, DSLT-MF(1204)는, 결과들(예컨대, 업데이트된 리소스 표현)을 지속적이게 만들고 다른 트랜잭션들이 리소스 및 그 리소스의 업데이트된 상태에 액세스할 수 있게 하기 위해 리소스에 대한 잠금을 또한 해제함으로써, 결과들을 커밋할 것을 표적화된 DSLT-CF(1208 및 1210)에 지시하도록 진행할 수 있다고 결정한다. DSLT-MF(1204)가 모든 표적들로부터 성공적인 실행 응답을 수신하지 못한 경우에서, DSLT-MF(1204)는, 임의의 완료 기준들이 트랜잭션에 대해 구성되거나 그의 정책들 중 임의의 정책에 특정된지 여부를 확인할 수 있다. 완료 기준들이 특정된 경우, DSLT-MF(1204)는, 기준들이 DSLT-MF(1204)가 진행할 수 있게 하는지 또는 아닌지를 확인할 수 있다(예컨대, 기준들은, 모든 표적들 대신 표적들의 하위 세트 상에서만 트랜잭션이 완료되도록 요구된다는 것을 특정할 수 있음). 대안적으로, 실행된 트랜잭션들 중 하나 이상이 실패하는 경우에서, DSLT-MF(1204)는 트랜잭션이 자신의 구성 파라미터를 통해 또는 정책 설정을 통해 재시도되도록 구성되는지 또는 아닌지 여부를 확인할 수 있다. 재시도들이 허용되는 경우, DSLT-MF(1204)는 실패한 트랜잭션을 재시도할 수 있다. DSLT-MF(1204)가, 완료 기준들이 충족될 수 없고 트랜잭션을 재시도할 수 없다고 결정하는 경우에서, DSLT-MF(1204)는 트랜잭션을 중단하기로 선택할 수 있다. 트랜잭션을 중단하기 위해, DSLT-MF(1204)는 트랜잭션 표적들 각각(이러한 예에서는, IoT 디바이스(1234 및 1236) 상의 DSLT-CF들)에 중단 명령을 전송한다. 중단을 수신할 시, DSLT-CF(1210)는, 트랜잭션에 의해 표적화된 리소스(들)에 대해 이루어진 임의의 수정들을, 그 리소스(들)가 트랜잭션의 시작 전에 있던 상태와 동일한 상태로 복귀되도록 롤백함으로써 트랜잭션을 중단한다. DSLT-CF(1210)는 또한 표적화된 리소스(들)에 대한 잠금을 해제할 수 있다.
도 21의 단계(15)에서, IoT 서버(1230) 상의 DSLT-MF(1204)는, 각각의 표적화된 DSLT-CF(1208 및 1210)에 트랜잭션을 커밋할 것을 명령하기 위한 요청을 전송한다. 이러한 명령은, DSLT-MF(1204)가, DSLT-CF(1208 및 1210)에 트랜잭션을 커밋할 것을 지시하는 각각의 IoT 디바이스 상에서 호스팅되는 DSLT 리소스 내의 명령 속성을 업데이트하는 것에 의해 송출될 수 있다.
도 21의 단계(16)에서, 트랜잭션을 커밋하기 위한 명령을 수신할 시, 각각의 디바이스 상의 DSLT-CF(1208 및 1210)는, 트랜잭션을 실행할 때 이루어졌을 수 있는 리소스에 대한 임의의 업데이트들을 그 상태가 지속적이도록 저장한다. 커밋된 리소스의 상태에 대한 임의의 업데이트들에 기반하여, DSLT-CF(1208 및 1210)는 또한, 업데이트된 상태에 관한 통지들을, 표적화된 리소스에 가입했을 수 있는 시스템 내의 임의의 다른 엔티티들에 전송할 수 있다. 그런 다음, DSLT-CF(1208 및 1210)는 표적화된 리소스에 대한 임의의 잠금들을 해제하고, 임의의 저장된 동작 전 상태를 삭제할 수 있다.
도 21의 단계(17)에서, 일단 커밋이 완료되면, 각각의 DSLT-CF(1208 및 1210)는 커밋의 결과들 및 그것이 성공적이었는지 여부로 DSLT-MF(1204)에 다시 응답한다.
도 21의 단계(18)에서, IoT 서버 상의 DSLT-MF(1204)는, 모든 표적화된 DSLT-CF들(1208 및 1210)(즉, IoT 디바이스들(1234 및 1236) 둘 모두)이 그들이 표적화된 리소스들 상에서 트랜잭션을 성공적으로 커밋했음을 응답하는 것을 검출한다. 커밋들 중 하나 이상이 실패하는 경우에서, DSLT-MF(1204)는 트랜잭션이 자신의 구성 파라미터를 통해 또는 정책 설정을 통해 재시도되도록 구성되는지 또는 아닌지 여부를 확인할 수 있다. 재시도들이 허용되는 경우, DSLT-MF(1204)는 실패한 트랜잭션을 재시도할 수 있다. DSLT-MF(1204)가, 완료 기준들이 충족될 수 없고 트랜잭션을 재시도할 수 없다고 결정하는 경우에서, DSLT-MF(1204)는 트랜잭션에 대한 오류 조건을 보고할 수 있다.
도 21의 단계(19)에서, DSLT-MF(1204)는, IoT 애플리케이션의 DSLT-TF(1202)로부터 자신이 수신한 DSLT에 대응하는 자신의 국부적으로 호스팅된 DSLT 리소스를 업데이트한다. 이러한 업데이트에는, 트랜잭션들이 성공적이었는지 여부 및 성공적이지 않은 경우에는 실패에 대한 원인 또는 이유를 표시하는, 자신이 IoT 디바이스들에 배포하는 DSLT들 각각의 상태가 포함된다.
도 21의 단계(20)에서, 일단 DSLT 처리가 완료되면, IoT 서버 상의 DSLT-MF(1204)는 IoT 애플리케이션 상의 DSLT-TF(1202)에 통지할 수 있고, 이는 DSLT의 결과들을 포함한다. DSLT-MF(1204)는, DSLT의 전체 상태뿐만 아니라, 개별 표적들 상에서 수행된 각각의 배포된 트랜잭션의 개별 상태를 포함할 수 있다. 이는, 실패들의 원인을 설명하는 오류 또는 디버그 정보를 포함할 수 있다. 이는, 기술자들 또는 운영자들이, 다른 DSLT를 송출하려 재시도하기 전에 문제들을 검출하고 장애가 있는 디바이스들을 교환하거나 복구할 수 있게 할 수 있다.
도 21의 단계(21)에서, 완료된 DSLT의 통지를 수신한 후에, IoT 애플리케이션의 DSLT-TF(1202)는 자신이 통지를 수신했다는 확인으로 DSLT-MF(1204)에 다시 응답할 수 있다.
도 21의 단계(22)에서, 임의의 시점에, IoT 애플리케이션의 DSLT-TF(1202)가 DSLT 처리의 상태를 확인하기를 희망하는 경우, DSLT-TF(1202)는 상태를 확인하기 위해 DSLT-MF(1204)에 질의할 수 있다. 질의 요청을 수신할 때, DSLT-MF(1204)는, 자신이 대응하는 DSLT 리소스에 유지하는 DSLT의 상태를 확인할 수 있다.
도 21의 단계(23)에서, DSLT-MF(1204)는, DLTS 상태 질의를 개시한 DSLT-TF(1202)에 DSLT 처리의 상태를 반환한다.
DSLT 시퀀싱 절차
도 22는 DSLT 시퀀싱 절차를 도시한다.
도 22의 단계(1)는 임의적 단계이다. 도 22의 단계(1)에서, IoT 애플리케이션의 DSLT-TF(1202)는 DSLT 시퀀스 정책 리소스들을 생성하기 위한 요청(들)을 IoT 서버의 DSLT-MF(1204)에 전송한다. 각각의 정책 리소스는 DSLT-MF가 DSLT 시퀀스 요청들을 처리하는 방식을 제어하기 위한 하나 이상의 규칙을 포함할 수 있다. 이러한 규칙들은, DSLT 시퀀스 스케줄링, DSLT 시퀀스들의 재시도, DSLT 시퀀스들의 우선순위화, DSLT 시퀀스들에 대한 실행 및 완료 기준들에 관한 것일 수 있다. 대안적으로, IoT 서버의 DSLT-MF(1204)에는 DSLT 시퀀스 정책들이 사전 프로비저닝될 수 있다.
도 22의 단계(2)는 임의적 단계이다. 도 22의 단계(2)에서, IoT 서버의 DSLT-MF(1204)는 DSLT 시퀀스 정책 리소스들을 생성하기 위한 요청을 수신하여 처리한다. DSLT-MF(1204)는 정책 리소스를 생성하고, 또한, 정책들에서 특정된 규칙들로 자신의 DSLT 정책 엔진(1308)을 구성한다.
도 22의 단계(3)는 임의적 단계이다. 도 22의 단계(3)에서, IoT 서버의 DSLT-MF(1204)는, 정책 리소스들에서 정의된 규칙들이 수락되었는지 아닌지 여부를 IoT 애플리케이션의 DSLT-TF(1202)에 알리기 위해 그 DSLT-TF(1202)에 응답을 반환한다. 그렇지 않은 경우, DSLT-MF(1204)는 DSLT-MF(1204)에 의해 수락되었던 규칙들의 수정된 버전을 제공할 수 있다.
도 22의 단계(4)에서, IoT 애플리케이션의 DSLT-TF(1202)는 DSLT-SEQ-TRIGGER 요청을 IoT 서버의 DSLT-MF(1204)에 전송한다. 요청은, 표적화된 노드들(예컨대, IoT 디바이스 1 및 IoT 디바이스 2)의 세트, 이러한 노드들 상에서 수행할 DSLT들의 목록, 시퀀스를 수행할 때의 스케줄, 시퀀스 실행 기준들의 세트, 우선순위, 트랜잭션들의 시퀀스를 처리하려는 시도들이 실패한 경우에서의 재시도 횟수, 시퀀스 완료 기준들의 세트, DSLT 시퀀스 식별자, 및 DSLT-MF(1204)가 비-차단 방식으로 시퀀스를 처리하는 데 사용할 수 있는 접촉 정보와 같은 몇몇 파라미터들을 포함할 수 있다.
도 22의 단계(5)에서, IoT 서버의 DSLT-MF(1204)는 DSLT-SEQ-TRIGGER 요청을 수신하여 처리하기 시작한다. DSLT-MF(1204)는, DSLT 시퀀스를 처리하는 동안 트랜잭션 시퀀스 상태를 계속 추적하기 위해 DSLT 시퀀스 리소스를 생성한다. DSLT-MF(1204)는, 단계(4)에서 설명된 DSLT 시퀀스 요청 파라미터들에 포함된 정보로 리소스의 속성들을 구성한다.
도 22의 단계(6)에서, IoT 서버의 DSLT-MF(1204)는, 자신이 요청을 수신했고 그 요청을 처리하기 시작했다는 것을 표시하는 응답을 IoT 애플리케이션의 DSLT-TF(1202)에 반환함으로써 비-차단 방식으로 요청을 처리한다. 대안적으로, DSLT-MF(1204)는 이러한 요청을 차단 방식으로 처리할 수 있다.
도 22의 단계(7)에서, IoT 서버의 DSLT-MF(1204)는 시퀀스에 의해 표적화된 리소스들의 목록을 발견하기 위해 요청을 파싱한다. DSLT-MF(1204)는, 표적화된 리소스들이 IoT 서버 상에서 국부적으로 호스팅되지 않고 오히려 IoT 디바이스들 1 및 2에 의해 호스팅됨을 검출한다. 그러므로, DSLT-MF(1204)는 이러한 표적화된 디바이스들을 배포하기 위해 시퀀스 내의 제1/다음 대응하는 DSLT를 준비한다. DSLT를 배포하기 전에, DSLT-MF(1204)는 먼저, 원래의 DSLT-SEQ-TRIGGER 요청 또는 임의의 스케줄 관련 정책들에 임의의 스케줄 정보가 명시적으로 구성되었는지를 확인한다. DSLT-MF(1204)는 또한, 원래의 DSLT-SEQ-TRIGGER 요청 또는 임의의 정책들에 임의의 우선순위가 명시적으로 구성되었는지를 확인한다. 명시적으로 구성된 경우, DSLT-MF(1204)는, 자신이 수신하고 처리를 요구하는 임의의 다른 DSLT-SEQ-TRIGGER 요청들이 존재하는지를 확인한다. 존재하는 경우, DSLT-MF(1204)는 우선순위 정보를 사용하여 DSLT-SEQ-TRIGGER 요청들의 실행을 서로에 대해 순위화 및 순서화한다. 일단 스케줄 및 우선순위가 그것을 허용하면, DSLT-MF(1204)는 그에 따라 DSLT-REQ 요청들을 표적들에 배포한다.
일단 스케줄 및 우선순위가 그것을 허용하면, DSLT-MF(1204)는 그에 따라 DSLT-REQ들을 표적들에 배포한다. DSLT-MF(1204)의 우선순위화 정책들에 따라, 활성으로 처리되고 있는 DSLT-SEQ-TRIGGER보다 더 높은 우선순위를 갖는 새로운 DSLT-SEQ-TRIGGER가 수신되는 경우, DSLT-MF(1204)는, 활성으로 처리되고 있는 DSLT-SEQ-TRIGGER를 완료하거나, 새로 도착된 더 높은 우선순위의 DSLT-SEQ-TRIGGER를 처리하기 위해 그를 선점대체할 수 있다. 시퀀스를 선점대체하는 경우에서, DSLT-MF(1204)는 나중에 다시 처리를 재시작하기 위하여 시퀀스를 중단 및 롤백할 수 있거나, DSLT-MF(1204)는 더 높은 우선순위의 시퀀스를 처리하는 동안 시퀀스 및 그의 연관된 DSLT들의 처리를 일시정지하고 그런 다음 나중에 그 처리를 재개할 수 있다. 이러한 중단 대 선점대체 결정은, 몇몇 인자들, 이를테면, 더 높은 우선순위의 시퀀스가 활성으로 처리되고 있는 더 낮은 우선순위의 시퀀스와 동일한 리소스들을 표적화하는지 여부에 기반할 수 있다. 이러한 경우에서, DSLT-MF(1204)는 더 낮은 우선순위의 시퀀스를 중단하기로 결정할 수 있는 반면, 2개의 시퀀스가 상이한 리소스들을 표적화하는 경우에 대해서는, DSLT-MF(1204)는 더 낮은 우선순위의 트랜잭션을 선점대체하거나 지원되는 경우에는 둘 모두를 병렬로 실행하기로 선택할 수 있다.
도 22의 단계(8)에서, IoT 디바이스(1234 및 1236) 상의 DSLT-CF들(1208 및 1210) 각각이 그들의 DSLT-REQ들을 수신한다. 둘 모두는 요청을 처리하고, 그들이 DSLT를 처리하는 동안 트랜잭션 상태를 계속 추적하기 위해 국부적 DSLT 리소스를 생성한다. DSLT-CF들(1208 및 1210)은 그들의 리소스들의 속성들을 DSLT-REQ 파라미터들에 포함된 정보로 구성한다. DSLT-CF들(1208 및 1210)은, 먼저, 표적화된 리소스(들)의 이용가능성을 확인함으로써, 트랜잭션을 처리하는 것을 시작한다. 리소스(들)가 IoT 디바이스에 국부적인 경우, DSLT-CF(1210)는, 리소스의 특정된 동작을 수행하기 위한 이용가능성, 및 현재 리소스를 예비하고 잠근 다른 트랜잭션들이 존재하지 않는다는 것을 확인한다. 리소스가 이용가능한 경우, DSLT-CF(1210)는, 현재 트랜잭션의 처리 동안 도달할 수 있는 다른 트랜잭션들로부터의 간섭 없이 리소스 상에서 자신이 트랜잭션을 수행할 수 있도록 그 리소스를 잠글 수 있다. DSLT-CF(1210)가 DSLT-REQ를 수신하고 요청이 국부적 디바이스 상에서 호스팅되지 않는 리소스를 표적화하는 것을 발견한 경우에서, DSLT-CF(1210)는 (가능하게는, 디바이스 상에서 국부적으로 호스팅되는 DSLT-MF(1204)의 보조로) 다른 디바이스 상의 DSLT-CF가 그것을 처리할 수 있도록 시스템 내의 다른 디바이스에 DSLT-REQ를 재표적화할 수 있다.
도 22의 단계(9)에서, 각각의 IoT 디바이스 상의 DSLT-CF(1210)는, 요청이 수신되었고, 트랜잭션에 대해 처리가 시작되었고, 표적화된 리소스가 이용가능하고, 다른 트랜잭션들로부터의 간섭 없이 현재 트랜잭션이 진행될 수 있기 위해 리소스가 잠겼음을 표시하는 상태를 IoT 서버의 DSLT-MF(1204)에 반환한다.
도 22의 단계(10)에서, IoT 서버 상의 DSLT-MF(1204)는, 모든 표적화된 DSLT-CF들(1208 및 1210)(즉, IoT 디바이스들(1234 및 1236) 둘 모두)이 그들이 표적화된 리소스들을 성공적으로 잠갔음을 응답하는 것을 검출한다. 결과적으로, DSLT-MF(1204)는, 표적화된 DSLT-CF(1210)에 트랜잭션을 실행할 것을 지시하도록 진행할 수 있다고 결정한다. DSLT-MF(1204)가 모든 표적들로부터 성공적인 잠금 응답을 수신하지 못한 경우에서, DSLT-MF(1204)는, 임의의 완료 기준들이 트랜잭션에 대해 구성되거나 그의 정책들 중 임의의 정책에 특정된지 여부를 확인할 수 있다. 완료 기준들이 특정된 경우, DSLT-MF(1204)는, 기준들이 DSLT-MF(1204)가 진행할 수 있게 하는지 또는 아닌지를 확인할 수 있다(예컨대, 기준들은, 모든 표적들 대신 표적들의 하위 세트 상에서만 트랜잭션이 완료되도록 요구된다는 것을 특정할 수 있음). 대안적으로, 트랜잭션들 중 하나 이상이 표적화된 리소스를 잠그는 데 실패하는 경우에서, DSLT-MF(1204)는 트랜잭션이 자신의 구성 파라미터를 통해 또는 정책 설정을 통해 재시도되도록 구성되는지 또는 아닌지 여부를 확인할 수 있다. 재시도들이 허용되는 경우, DSLT-MF(1204)는 실패한 트랜잭션을 재시도할 수 있다. DSLT-MF(1204)가, 완료 기준들이 충족될 수 없고 트랜잭션을 재시도할 수 없다고 결정하는 경우에서, DSLT-MF(1204)는 트랜잭션을 중단하기로 선택할 수 있다. 트랜잭션을 중단하기 위해, DSLT-MF(1204)는 트랜잭션 표적들 각각(이러한 예에서는, IoT 디바이스(1234 및 1236) 상의 DSLT-CF들(1208 및 1210))에 중단 명령을 전송한다. 중단을 수신할 시, DSLT-CF(1210)는, 트랜잭션에 의해 표적화된 리소스(들)에 대해 이루어진 임의의 수정들을, 그 리소스(들)가 트랜잭션의 시작 전에 있던 상태와 동일한 상태로 복귀되도록 롤백함으로써 트랜잭션을 중단한다. DSLT-CF(1210)는 또한 표적화된 리소스(들)에 대한 잠금을 해제할 수 있다.
대안적으로, DSLT-CF(1210)가 단계(8)에서 리소스를 잠글 수 없었던 경우, DSLT-CF(1210)는 리소스가 이용가능하지 않은 이유(리소스가 존재하지 않음, 불충분한 액세스 권한들, 리소스가 이미 잠겨 있음)에 관한 표시를 제공할 수 있다. 리소스가 잠긴 경우, DSLT-CF(1210)는 또한 (잠긴 리소스와 연관된 타임아웃들에 기반하여) 리소스가 잠금해제될 수 있는 시간에 관한 표시를 제공할 수 있다. 그러한 경우에서, DSLT-MF(1204)는 (DSLT-CF(1210)에 의해 제공되는 정보에 기반하여) 얼마간의 나중의 시간에 트랜잭션의 재시도를 시도할 수 있다.
도 22의 단계(11)에서, IoT 서버(1230) 상의 DSLT-MF(1204)는, 각각의 표적화된 DSLT-CF(1208 및 1210)에 트랜잭션을 실행할 것을 명령하기 위한 요청을 전송한다. 이러한 명령은, DSLT-MF(1204)가, DSLT-CF(1208 및 1210)에 트랜잭션을 실행할 것을 지시하는 각각의 IoT 디바이스(1234 및 1236) 상에서 호스팅되는 DSLT 리소스 내의 명령 속성을 업데이트하는 것에 의해 송출될 수 있다.
도 22의 단계(12)에서, 트랜잭션을 실행하기 위한 명령을 수신할 시, 각각의 디바이스 상의 DSLT-CF(1208 및 1210)는 표적화된 리소스 상에서 트랜잭션에 특정된 동작을 수행한다. 표적화된 리소스 상에서의 동작의 결과로서, IoT 디바이스에서의 다수의 리소스들의 상태가 변할 수 있다. DSLT-CF(1208 및 1210)는, DSLT-REQ가 중단되고 롤백될 필요가 있는 경우, 필요한 경우에는 (동작의 실행 전의) 동작 전 상태의 사본을 유지한다.
도 22의 단계(13)에서, 일단 실행이 완료되면, 각각의 DSLT-CF(1208 및 1210)는 실행의 결과들 및 그것이 성공적이었는지 여부로 DSLT-MF(1204)에 다시 응답한다.
도 22의 단계(14)에서, IoT 서버 상의 DSLT-MF(1204)는, 모든 표적화된 DSLT-CF들(1208 및 1210)(즉, IoT 디바이스들(1234 및 1236) 둘 모두)이 그들이 표적화된 리소스들 상에서 트랜잭션을 성공적으로 실행했음을 응답하는 것을 검출한다. 그런 다음, DSLT-MF(1204)는, 시퀀스 내에 임의의 잔여 DSLT들이 존재하는지 여부를 확인한다. 존재하는 경우, DSLT-MF(1204)는 다음 DSLT를 준비하고 단계들(7-14)을 반복한다. 시퀀스 내에 잔여 DSLT들이 존재하지 않는 경우, DSLT-MF(1204)는, 시퀀스의 일부로서 처리된 모든 DSLT들의 결과들을 커밋할 것을 표적화된 DSLT-CF(1208)에 지시하도록 진행할 수 있다고 결정한다. 이를 지속적이게 만들고 리소스에 대한 잠금을 해제함으로써, 다른 트랜잭션들이 리소스 및 그의 업데이트된 상태에 액세스할 수 있게 한다. DSLT-MF(1204)가 모든 표적들로부터 성공적인 실행 응답을 수신하지 못한 경우에서, DSLT-MF(1204)는, 임의의 완료 기준들이 트랜잭션에 대해 구성되거나 그의 정책들 중 임의의 정책에 특정된지 여부를 확인할 수 있다. 완료 기준들이 특정된 경우, DSLT-MF(1204)는, 기준들이 DSLT-MF(1204)가 진행할 수 있게 하는지 또는 아닌지를 확인할 수 있다(예컨대, 기준들은, 모든 표적들 대신 표적들의 하위 세트 상에서만 트랜잭션이 완료되도록 요구된다는 것을 특정할 수 있음). 대안적으로, 실행된 트랜잭션들 중 하나 이상이 실패하는 경우에서, DSLT-MF(1204)는 트랜잭션이 자신의 구성 파라미터를 통해 또는 정책 설정을 통해 재시도되도록 구성되는지 또는 아닌지 여부를 확인할 수 있다. 재시도들이 허용되는 경우, DSLT-MF(1204)는 실패한 트랜잭션을 재시도할 수 있다. DSLT-MF(1204)가, 완료 기준들이 충족될 수 없고 트랜잭션을 재시도할 수 없다고 결정하는 경우에서, DSLT-MF(1204)는 트랜잭션을 중단하기로 선택할 수 있다. 트랜잭션을 중단하기 위해, DSLT-MF(1204)는 트랜잭션 표적들 각각(이러한 예에서는, IoT 디바이스(1234 및 1236) 상의 DSLT-CF들(1208 및 1210))에 중단 명령을 전송한다. 중단을 수신할 시, DSLT-CF(1208 및 1210)는 시퀀스 내의 각각의 트랜잭션을 중단함으로써 시퀀스를 중단한다. 이는, 시퀀스 내의 트랜잭션들에 의해 표적화된 리소스(들)에 대해 이루어진 임의의 수정들을, 그 리소스(들)가 시퀀스의 시작 전에 있던 상태와 동일한 상태로 복귀되도록 롤백하는 것을 초래한다. DSLT-CF(1208 및 1210)는 또한 표적화된 리소스들에 대한 잠금을 해제할 수 있다.
도 22의 단계(15)에서, IoT 서버(1230) 상의 DSLT-MF(1204)는, 실행된 각각의 DSLT에 대한 각각의 표적화된 DSLT-CF(1208 및 1210)에 일련의 커밋 요청들을 전송한다. 이러한 명령은, DSLT-MF(1204)가, DSLT-CF(1208 및 1210)에 트랜잭션을 커밋할 것을 지시하는 각각의 IoT 디바이스(1234 및 1236) 상에서 호스팅되는 DSLT 리소스 내의 명령 속성을 업데이트하는 것에 의해 송출될 수 있다.
도 22의 단계(16)에서, 주어진 DSLT를 커밋하기 위한 각각의 명령을 수신할 시, 각각의 디바이스 상의 DSLT-CF(1208 및 1210)는, 트랜잭션을 실행할 때 이루어졌을 수 있는 리소스에 대한 임의의 업데이트들을 그 상태가 지속적이도록 저장한다. 커밋된 리소스의 상태에 대한 임의의 업데이트들에 기반하여, DSLT-CF(1208 및 1210)는 또한, 업데이트된 상태에 관한 통지들을, 표적화된 리소스에 가입했을 수 있는 시스템 내의 임의의 다른 엔티티들에 전송할 수 있다. 그런 다음, DSLT-CF(1208 및 1210)는 표적화된 리소스에 대한 임의의 잠금들을 해제하고, 임의의 저장된 동작 전 상태를 삭제할 수 있다.
도 22의 단계(17)에서, 일단 각각의 커밋이 완료되면, 각각의 DSLT-CF(1208 및 1210)는 커밋의 결과들 및 그것이 성공적이었는지 여부로 DSLT-MF(1204)에 다시 응답한다.
도 22의 단계(18)에서, IoT 서버 상의 DSLT-MF(1204)는, 모든 표적화된 DSLT-CF들(1208 및 1210)(즉, IoT 디바이스들(1234 및 1236) 둘 모두)이 그들이 개개의 표적화된 리소스들 상에서 시퀀스 내의 모든 트랜잭션들을 성공적으로 커밋했음을 응답하는 것을 검출한다. 커밋들 중 하나 이상이 실패하는 경우에서, DSLT-MF(1204)는 개개의 트랜잭션 시퀀스가 자신의 구성 파라미터를 통해 또는 정책 설정을 통해 재시도되도록 구성되는지 또는 아닌지 여부를 확인할 수 있다. 재시도들이 허용되는 경우, DSLT-MF(1204)는 실패한 트랜잭션 시퀀스를 재시도할 수 있다. DSLT-MF(1204)가, 완료 기준들이 충족될 수 없고 트랜잭션 시퀀스를 재시도할 수 없다고 결정하는 경우에서, DSLT-MF(1204)는 트랜잭션 시퀀스에 대한 오류 조건을 보고하기로 선택할 수 있다.
도 22의 단계(19)에서, DSLT-MF(1204)는, IoT 애플리케이션의 DSLT-TF(1202)로부터 자신이 수신한 DSLT-SEQ-TRIGGER 요청에 대응하는 자신의 국부적으로 호스팅된 DSLT 시퀀스 리소스를 업데이트한다. 이러한 업데이트에는, 시퀀스 내의 그리고 자신이 IoT 디바이스들에 배포한 DSLT들 각각의 상태가 포함된다. 이러한 상태는, 트랜잭션 시퀀스가 성공적이었는지 여부 및 성공적이지 않은 경우에는 실패에 대한 이유를 표시한다. DSLT-MF(1204)는 또한, 시퀀스 내의 임의의 실패한 DSLT들에 대한 개별 상태 및 실패 정보를 포함할 수 있다.
도 22의 단계(20)에서, 일단 DSLT 시퀀스 처리가 완료되면, IoT 서버 상의 DSLT-MF(1204)는 IoT 애플리케이션 상의 DSLT-TF(1202)에 통지할 수 있고, 이는 DSLT 시퀀스의 결과들을 포함한다. DSLT-MF(1204)는, DSLT 시퀀스의 전체 상태뿐만 아니라, 개별 표적들 상에서 수행된 시퀀스 내의 각각의 배포된 트랜잭션의 개별 상태를 포함할 수 있다. 이는, 실패들의 원인을 설명하는 오류 또는 디버그 정보를 포함할 수 있다. 이는, 기술자들 또는 운영자들이, 다른 DSLT를 송출하려 재시도하기 전에 문제들을 검출하고 장애가 있는 디바이스들을 교환하거나 복구할 수 있게 할 수 있다.
도 22의 단계(21)에서, 완료된 DSLT 시퀀스의 통지를 수신한 후에, IoT 애플리케이션의 DSLT-TF(1202)는 자신이 통지를 수신했다는 확인으로 DSLT-MF(1204)에 다시 응답할 수 있다.
도 22의 단계(22)에서, 임의의 시점에, IoT 애플리케이션의 DSLT-TF(1202)가 DSLT 시퀀스 처리의 상태를 확인하기를 희망하는 경우, DSLT-TF(1202)는 상태를 확인하기 위해 DSLT-MF(1204)에 질의할 수 있다. 질의 요청을 수신할 때, DSLT-MF(1204)는, 자신이 대응하는 DSLT 시퀀스 리소스에 유지하는 DSLT 시퀀스의 상태를 확인할 수 있다.
도 22의 단계(23)에서, DSLT-MF(1204)는, DLTS 상태 질의를 개시한 DSLT-TF(1202)에 DSLT 시퀀스 처리의 상태를 반환한다.
원엠투엠 분산형 서비스 계층 트랜잭션 실시예들
원엠투엠 아키텍처(문헌 [oneM2M TS-0001])를 향해 표적화된 DSLT 메커니즘들 및 절차들의 몇몇 실시예들이 아래에서 설명된다. 원엠투엠 아키텍처에 DSLT 지원을 부가하는 것은, 다수의 리소스들을 표적화하는 요청들의 세트를, 모든 요청들이 성공적으로 수행되거나 이들 중 어느 것도 수행되지 않도록 원자적 방식으로 수행될 수 있게 한다.
원엠투엠 아키텍처 내에서, DSLT-MF(1204) 및/또는 DSLT-CF(1210)는, 도 23에 도시된 바와 같이, 공통 서비스 엔티티(CSE)(즉, 서비스 계층 엔티티)의 새로운 트랜잭션 관리 공통 서비스 기능(CSF)으로서 실현될 수 있다.
이러한 트랜잭션 관리 CSF(2304)은 원엠투엠 시스템에서 DSLT 지원을 가능하게 하는 데 사용될 수 있다. 대안적으로, DSLT-MF(1204)는 또한, 하나 이상의 기존 원엠투엠 CSF들(도 6-1에 도시되지 않음)의 능력으로서 실현될 수 있다.
DSLT-TF(1202) 및/또는 DSLT-CF(1210) 기능성은 또한, 원엠투엠 애플리케이션 엔티티(AE)(2306)에 의해 지원될 수 있다. 예컨대, AE(2306)는 자신의 DSLT-TF(1202)를 통해 DSLT 요청을 개시하고, 이러한 요청을 CSE(2302)에 의해 호스팅되는 DSLT-MF(2304)에 전송할 수 있다. 대안적으로, AE(2306)는 CSE에 의해 호스팅되는 DSLT-MF(1204)로부터 자신의 DSLT-CF(1210)를 통해 DSLT 요청을 수신할 수 있다.
CSE(2302) 및 AE(2306)가 DSLT 기능성을 지원할 수 있게 하기 위해, 다음의 하위 항목들은 몇몇 DSLT 원엠투엠 실시예들을 정의한다.
원엠투엠 요청 파라미터들에 대한 DSLT 향상들
원엠투엠 아키텍처에서 DSLT들을 지원하기 위해, DSLT 및 DSLT 시퀀스 메시지 파라미터들 각각에 대한 새로운 원엠투엠 요청 파라미터들이 표 3 및 표 4에 정의되어 있다. 원엠투엠 요청들 내에서 이러한 파라미터들을 지원하는 것은, 다수의 원엠투엠 요청들이 서로 연관될 수 있게 하고 원엠투엠 요청들의 세트로서 원자적으로 함께 처리될 수 있게 한다.
트랜잭션 기반 처리를 지원하기 위해, 기존 원엠투엠 응답 유형 파라미터는, 2개의 부가적인 비-차단 응답 유형들인 비차단트랜잭션요청동기(nonBlockingTransactionRequestSynch) 및 비차단트랜잭션요청비동기(nonBlockingTransactionRequestAsynch)에 대한 지원을 부가하도록 향상될 수 있다. 이러한 2개의 응답 유형은, 요청이 호스팅 CSE에 의해 비-차단 및 원자적 트랜잭션으로서 처리될 것임을 특정하기 위해 발신자에 의해 사용될 수 있다. 이러한 새로운 값들 중 하나로 설정된 응답 유형을 갖는 요청을 수신할 때, 호스팅 CSE는, 나중의 항목에서 설명되는 바와 같이, 원엠투엠 <request> 리소스에 새로운 트랜잭션 지향 속성들을 부가하는 것을 지원할 수 있다. 이러한 새로운 트랜잭션 지향 응답 유형들 및 <request> 속성들은, 나중의 항목에서 상세히 설명되는 절차들에서 추가로 설명되는 바와 같이, 호스팅 CSE가 원자적 트랜잭션 지향 방식으로 프리미티브를 처리할 수 있게 한다. 대안적으로, 호스팅 CSE는 또한 다른 방식들로 DSLT들을 지원할 수 있다. 예컨대, 부가적인 DSLT 속성들 중 일부 또는 <sequence> 리소스와 함께 <transaction> 리소스를 지원함으로써 이루어진다.
원엠투엠 DSLT 리소스
원엠투엠 아키텍처에서 DSLT를 지원하기 위해, 몇몇 DSLT 관련 속성들이 사용될 수 있다. 이러한 속성들은, 도 24에 도시된 바와 같이, <request> 또는 <transaction> 리소스와 같은 기존 원엠투엠 리소스에 부가될 수 있다. 대안적으로, 이러한 속성들을 지원하기 위해 새로운 리소스 유형이 정의될 수 있다. 새로운 리소스 유형이 정의된 경우에 대해, 완전한 해결책을 제공하기 위해서는 <request> 및/또는 <transaction> 리소스에 이미 정의된 것들 중 일부와 유사한 부가적인 속성들이 또한 포함될 필요가 있을 수 있다. 이러한 기존 원엠투엠 속성들은 간략화를 위해 포함되어 있지 않다. 일 예는, 원엠투엠 요청 프리미티브를 포함하는 프리미티브 속성이다. 이러한 속성은 <request> 및 <transaction> 리소스에 존재하며, 도시되지 않는다.
이러한 새로운 속성들은, 발신자(예컨대, AE 또는 CSE)가 표적화된 CSE에 DSLT 요청을 송출할 수 있게 하고, CSE가 그것을 비-차단뿐만 아니라 원자적 방식으로 처리할 수 있게 한다.
Figure pct00010
Figure pct00011
Figure pct00012
원엠투엠 DSLT 시퀀스 리소스
원엠투엠 아키텍처에서 DSLT 시퀀스를 지원하기 위해, 몇몇 DSLT 시퀀스 속성들을 갖는 <sequence> 리소스가 도 25에 도시된다.
이러한 새로운 리소스 및 속성들은, 발신자(예컨대, AE 또는 CSE)가 DSLT 시퀀스 요청을 송출할 수 있게 하고, 호스팅 CSE가 DSLT들의 시퀀스를 비-차단뿐만 아니라 원자적 방식으로 처리할 수 있게 한다. 이러한 처리는, 시퀀스 내의 개별 DSLT들이 원자적 방식으로 실행될 뿐만 아니라 DSLT들의 전체 시퀀스가 또한 원자적 방식으로 실행되는 것(즉, 모든 DSLT들이 성공적으로 실행되거나 이들 중 어느 것도 실행되지 않음)을 보장하기 위해, 발신자를 대신하여 <sequence> 호스팅 CSE에 의해 개별 DSLT들의 시퀀스를 처리하는 것을 포함할 수 있다. 이는, DSLT들의 시퀀스를 처리하는 오버헤드 및 부담을 발신자로부터 오프로드할 수 있다. 이러한 기능성은 발신자가 DSLT 시퀀스들을 전송하기 위해 반복된 요청들을 행하는 경우들에 특히 유용할 수 있다. 이러한 반복된 DSLT 시퀀스들 자체를 처리해야 하기 보다는, 발신자는 이러한 작업을 자신을 대신하여 수행하도록 <sequence> 호스팅 CSE에 오프로드할 수 있다.
시퀀스 내의 임의의 DSLT들이 <sequence> 호스팅 CSE에 의해 호스팅되는 국부적 리소스를 표적화하는 경우, <sequence> 호스팅 CSE는 이러한 DSLT들 그 자체를 원자적 방식으로 처리할 수 있다. 이러한 처리 동안, <sequence> 호스팅 CSE는 이러한 국부적 리소스들을 잠글 수 있으며, 활성으로 처리되고 있는 시퀀스 내의 DSLT들에 의해 특정된 동작들 외에는 그 리소스들 상에서 어떠한 다른 동작들도 수행되지 않음을 보장할 수 있다. 일단 활성 시퀀스의 처리가 성공적으로 완료되고 커밋되면, 이러한 잠금은 해제될 수 있다.
시퀀스 내의 임의의 DSLT들이 원격 CSE들 상에서 호스팅되는 리소스들을 표적화하는 경우, <sequence> 호스팅 CSE는, DSLT 속성들을 갖는 <request> 또는 <transaction> 리소스들을 원격 CSE들 상에 생성함으로써 원격 CSE들에 DSLT 요청들을 전송할 수 있다. 이어서, <sequence> 호스팅 CSE는, DSLT가 원자적 방식으로 처리됨을 보장하기 위해, 원격 CSE들 상의 이러한 <request> 또는 <transaction> 리소스들의 상태를 관리할 수 있다. <sequence> 호스팅 CSE는, 표적화된 리소스들에 대한 잠금을 획득할 수 있다는 원격 CSE들로부터의 통지들을 대기할 수 있다. 일단 통지들이 수신되면, 이어서, <sequence> 호스팅 CSE는, 대응하는 <request> 또는 <transaction> 리소스의 명령 속성을 업데이트함으로써, DSLT를 실행할 것을 원격 CSE들에 지시할 수 있다. 이어서, 원격 CSE는 트랜잭션이 성공적으로 실행되었다는 원격 CSE들로부터의 통지를 대기할 수 있다. 일단 통지가 수신되면, <sequence> 호스팅 CSE는, 대응하는 <request> 또는 <transaction> 리소스의 명령 속성을 다시 업데이트함으로써, 트랜잭션의 결과들이 지속적이도록 결과들을 커밋할 것을 원격 CSE들에 지시할 수 있다. 이어서, <sequence> 호스팅 CSE는 결과들이 성공적으로 커밋되었다는 원격 CSE들로부터의 통지들을 대기할 수 있다. 커밋이 성공적이었다는 통지가 일단 수신되면, <sequence> 호스팅은 시퀀스 요청의 처리를 완료하고 그 요청의 발신자에 응답을 반환할 수 있다. 이러한 응답은 차단 또는 비-차단 방식으로 반환될 수 있다. 이러한 처리 동안의 임의의 단계에서, 원격 CSE가 시퀀스 내의 임의의 DSLT들을 성공적으로 잠그거나, 실행하거나, 또는 커밋할 수 없는 경우, <sequence> 호스팅 CSE는 시퀀스를 중단하고, 대응하는 <request> 또는 <transaction> 리소스의 명령 속성을 다시 업데이트함으로써, 표적화된 리소스들이 그들의 호스팅 CSE들에 의해 롤백됨을 보장할 수 있다. 이러한 롤백에 후속하여, 리소스들은 그들이 DSLT 시퀀스 처리가 시작되기 전에 있던 상태와 동일한 상태를 반영할 수 있다.
Figure pct00013
Figure pct00014
원엠투엠 DSLT 정책 리소스(들)
원엠투엠 아키텍처에서 DSLT 정책 구성을 지원하기 위해, 몇몇 DSLT 정책 속성들이 표 10에 정의된다. 이러한 속성은, 기존 원엠투엠 리소스, 이를테면, 원엠투엠 CMDH 기능성에 대해 정의된 것들과 같은 기존 원엠투엠 <mgmtObj> 전문화(들)에 부가될 수 있다. 대안적으로, 이러한 속성들, 이를테면 DSLT 기능성에 특정적인 새로운 원엠투엠 <mgmtObj> 전문화들을 지원하기 위해 새로운 리소스 유형이 정의될 수 있다. 예컨대, 새로운 전문화들은, DSLT 스케줄링 정책들, DSLT 재시도 정책들, DSLT 우선순위화 정책들, DSLT 완료 기준 정책들 및 DSLT 시퀀싱 정책들에 대해 정의될 수 있다.
이러한 새로운 속성들은, 발신자(예컨대, AE 또는 CSE)가, CSE에 DSLT 관련 정책들을 구성하여 그것이 DSLT 요청들을 처리하는 방식을 제어할 수 있게 한다.
Figure pct00015
원엠투엠 < group > 리소스에 대한 DSLT 향상들
하나 이상의 CSE 상에서 호스팅되는 다수의 표적화된 리소스들에 대한 DSLT의 원자적 배포 및 처리를 지원하기 위해, 원엠투엠 <group> 리소스에 대한 새로운 <transactionFanOutPoint> 가상 리소스 및 새로운 트랜잭션상태(transactionState) 속성이 도 26에 도시된 바와 같이 사용될 수 있다. 이러한 새로운 리소스 및 속성은 DSLT 요청의 발신자에 의해 임의적으로 사용될 수 있다. 이러한 리소스가 사용될 때, 그룹 호스팅 CSE는 발신자를 대신하여 DSLT 요청의 처리를 취급할 수 있다. 이러한 처리는, 그룹에 의해 특정된 구성원 리소스들 각각에 대한 DSLT의 팬아웃을 포함할 수 있다. 구성원 리소스들이 원격 CSE들 상에서 호스팅되는 경우, 그룹 호스팅 CSE는 구성원 리소스를 표적화하는 <request> 또는 <transaction> 리소스를 생성함으로써 DSLT를 원격 CSE로 팬아웃할 수 있다. 처리는 또한, 그룹 호스팅 CSE가 각각의 대응하는 구성원 리소스에 대한 각각의 DSLT의 상태를 관리하는 것을 포함할 수 있다. 이는, DSLT들이 서로에 대해 원자적 방식으로 실행됨(즉, 전부가 성공적으로 실행되거나 이들 중 어느 것도 실행되지 않음)을 보장하기 위해 발신자를 대신하여 행해질 수 있다. 이는, DSLT를 처리하는 오버헤드 및 부담을 발신자로부터 오프로드할 수 있다. 이러한 기능성은 발신자가 많은 수의 표적들에 DSLT들을 전송하기 위해 반복된 요청들을 행하는 경우들에 특히 유용할 수 있다. 많은 수의 표적화된 리소스들에 대한 이러한 반복된 DSLT들 자체를 처리해야 하기 보다는, 발신자는 이러한 작업을 자신을 대신하여 수행하도록 그룹 호스팅 CSE에 오프로드할 수 있다. 대안적으로, DSLT의 발신자가 오히려 DSLT를 스스로 관리할 경우, DSLT의 발신자는 그렇게 할 수 있고, 이러한 새로운 리소스를 사용하지 않을 수 있다.
이러한 가상 리소스는 표현을 갖지 않으며, 오히려, 이는 <group> 리소스의 자식 리소스이다. 원엠투엠 요청 프리미티브가 <transactionFanOutPoint> 리소스에 전송될 때마다, 그룹 호스팅 CSE는, 부모 <group> 리소스의 구성원ID(memberID)들의 속성에 의해 특정된 구성원들 각각에 대응하는 DSLT 생성 요청을 팬아웃함으로써 요청을 처리할 수 있다. 각각의 DSLT 생성 요청에 대해, 그것이 구성원에게 팬아웃되는 경우, 그룹 호스팅 CSE는 발신자로부터 자신이 수신한 원래의 요청 프리미티브로 속성을 구성할 수 있는데, 발신자에 의해 또는 그룹 호스팅 CSE에서 구성된 국부적 정책에 의해 특정되는 경우, 상태 속성을 "초기" 값으로 그리고 실행시간 속성을 결과 만료 시간 파라미터보다 작은 값으로 구성할 수 있다. 이후, 그룹 호스팅 CSE는 팬아웃된 DSLT 요청들의 취급을, 이들 전부가 서로에 대해 원자적 방식으로 처리되도록(즉, 모든 팬아웃된 트랜잭션들이 성공적으로 완료되거나 모두가 중단되도록) 조정할 수 있다. 구성원 호스팅 CSE들에 팬아웃된 DSLT 생성 요청들에 대해, 이러한 CSE들은 그들이 특정된 실행 시간에 구성원 리소스 상에서 특정된 프리미티브를 수행할 수 있는지 여부를 확인할 수 있다. 확인이 성공적인 경우, 구성원 호스팅 CSE는, 그들이 DSLT를 성공적으로 생성했다는 것을 그룹 호스팅 CSE에 다시 응답할 수 있다. 성공적이지 않은 경우, 구성원 호스팅 CSE는 실패로 다시 응답할 수 있다. 트랜잭션의 처리 동안 그룹 호스팅 CSE에 의해 타이머가 유지될 수 있다. 타이머가 만료되기 전에 각각의 구성원 호스팅 CSE로부터 성공적인 DSLT 생성 응답들이 수신되는 경우, 트랜잭션은 진행 및 실행되도록 허용된다. 그룹 호스팅 CSE는, 각각의 구성원 호스팅 CSE에, 트랜잭션을 실행 및 커밋하도록 지시하기 위한 명령들을 임의적으로 전송할 수 있다. 트랜잭션이 진행하도록 허용되지 않는 경우, 그룹 호스팅 CSE는, 자신이 DSLT를 성공적으로 생성했음을 표시하는 임의의 구성원 호스팅 CSE에 DSLT 삭제 요청들을 전송함으로써 트랜잭션을 중단할 수 있다. 트랜잭션이 실행하도록 허용되는 경우, 구성원 상에서 실행되는 각각의 요청 프리미티브로부터의 개별 응답들이 그룹 호스팅 CSE에 반환될 수 있다. 이어서, 그룹 호스팅 CSE는 응답들을 종합하여 결과들을 발신자에 반환할 수 있다. 응답들의 종합 동안 그룹 호스팅 CSE에 의해 타이머가 또한 유지될 수 있다. 응답들은, 모든 응답들이 수신된 경우 또는 타이머가 만료될 때 종합된다. 시간이 만료한 이후에 수신된 응답들은 폐기될 수 있다. 이러한 처리 동안의 임의의 단계에서, 그룹 호스팅 CSE가, 그룹 구성원들 각각으로부터, 그들이 DSLT를 잠그거나, 실행하거나, 또는 커밋할 수 있다는 성공적인 확인을 받지 못하는 경우, 그룹 호스팅 CSE는 DSLT를 중단하고, 표적화된 구성원 리소스들이 그들 개개의 구성원 호스팅 CSE들에 의해 롤백됨을 보장할 수 있다. 이러한 롤백에 후속하여, 리소스들은 그들이 DSLT 처리가 시작되기 전에 있던 상태와 동일한 상태를 반영할 수 있다. 그룹 호스팅 CSE는 또한, 트랜잭션의 처리 상태(예컨대, 초기, 잠김, 실행됨, 커밋됨, 또는 중단됨)로 업데이트된 트랜잭션상태 속성을 유지할 수 있다.
다른 실시예에서, 새로운 속성(예컨대, 트랜잭션팬아웃인에이블(transactionFanOutEnable))이 <group> 리소스에 대신 부가될 수 있다. 이러한 속성은, <group>의 기존 <fanOutPoint> 가상 리소스를 표적화하는 요청이 DSLT 요청으로서 처리될지 또는 비-DSLT 요청으로서 처리될지를 자격검증하는 데 사용될 수 있다. 이러한 대안은 도 26에 도시되지 않는다.
또 다른 실시예에서, 그룹 호스팅 CSE는 대신, 원엠투엠 <group> 리소스의 기존 <fanoutPoint>를 표적화하는 요청이 DSLT로서 처리될지 아닐지 여부를 검출하기 위해, 요청에서의 하나 이상의 DSLT 관련 파라미터의 존재에 의존할 수 있다.
원엠투엠 잠금 속성
모든 원엠투엠 리소스들에 대한 원엠투엠 "잠금" 공통 속성의 부가가 사용될 수 있다. 이러한 새로운 속성은, 리소스가 잠긴 상태에 있는 있는지 아닌지의 통고(advertise)를 또한 계속 추적하기 위해 호스팅 CSE에 의해 사용될 수 있다. 예컨대, DSLT가 처리되고 있을 때, DSLT의 표적화된 리소스들이 잠길 수 있다. 잠길 때, 잠금 속성은 그 리소스가 잠겼음을 반영하도록 업데이트될 수 있다. 이러한 속성은 참 또는 거짓과 같은 값으로 구성될 수 있다. 대안적으로, 이러한 속성은, 상이한 유형들이 잠금들(예컨대, 업데이트들에 대해서만 잠김)을 반영하는 값들을 지원할 수 있다.
원엠투엠 DSLT 식별자들
DSLT 기능성을 지원하기 위해, 원엠투엠 DSLT 식별자들이 사용될 수 있다. 개별 DSLT 요청의 처리가 각각이 자신 고유의 별도의 원엠투엠 요청 식별자들을 갖는 다수의 원엠투엠 요청들을 요구할 수 있으므로, DSLT 식별자는 이러한 별개의 원엠투엠 요청들을 단일 DSLT로 연관시키기 위한 메커니즘을 제공한다. 이러한 연관 수준은, DSLT를 구성하는 개별 원엠투엠 요청들의 분산되고 원자적인 처리를 가능하게 한다. 표 11은 원엠투엠 DSLT 식별자 포맷들의 설명을 제공한다. 표 12는 원엠투엠 DSLT 기반 요청 식별자들의 구조의 설명을 제공한다.
Figure pct00016
Figure pct00017
DSLT 시퀀스 기능성을 지원하기 위한, DSLT 시퀀스에 대한 원엠투엠 식별자가 설명된다. DSLT 시퀀스의 처리가 다수의 DSLT들의 처리를 요구할 수 있고, 각각의 DSLT의 처리가 각각이 자신 고유의 별도의 원엠투엠 요청 식별자들을 갖는 다수의 원엠투엠 요청들의 처리를 요구할 수 있으므로, DSLT 시퀀스 식별자는 이러한 다수의 DSLT들 및 원엠투엠 요청들을 단일 DSLT 시퀀스로 연관시키기 위한 메커니즘을 제공한다. 이러한 연관 수준은, DSLT 시퀀스를 구성하는 개별 DSLT들 및 원엠투엠 요청들의 분산되고 원자적인 처리를 가능하게 한다. 표 13은 원엠투엠 DSLT 시퀀스 식별자 포맷들의 설명을 제공한다. 표 14는 원엠투엠 DSLT 시퀀스 기반 DSLT 식별자의 구조의 설명을 제공한다. 표 15는 원엠투엠 DSLT 시퀀스 기반 요청 식별자의 구조의 설명을 제공한다.
Figure pct00018
Figure pct00019
Figure pct00020
원엠투엠 DSLT 그룹 팬아웃 절차
도 27은 원엠투엠 DSLT 그룹 팬아웃 절차를 도시한다.
도 27의 단계(1)에서, 원엠투엠 <group> 리소스가 생성된다. 그룹의 구성원들은, ASN-CSE1 및 ASN-CSE2 상에서 호스팅되는 컨테이너 리소스들이도록 구성된다. 이러한 그룹은 DSLT-TF(1202)를 호스팅하는 AE 또는 시스템 내의 다른 AE에 의해 생성될 수 있다.
도 27의 단계(2)에서, DSLT-TF(1202) 기능을 호스팅하는 AE는, ASN-CSE1 및 ASN-CSE2에 의해 호스팅되는 컨테이너 리소스들 하에서 원엠투엠 <contentInstance>를 원자적으로 생성하기 위해 원엠투엠 DSLT 요청을 구축한다. 이러한 DSLT 요청은, 도 27에 도시된 바와 같이 원엠투엠 <contentInstance> 생성 프리미티브로서 구조화될 수 있다. 대안적으로, 이러한 DSLT 요청은, 자신의 프리미티브 속성 내에 <contentInstance> 생성 프리미티브를 캡슐화하는 원엠투엠 <transaction> 생성 요청 프리미티브로서 구조화될 수 있다. 도 27에 도시되진 않지만, 요청은, 동작을 수행할 때의 스케줄, 실행 기준들의 세트, 우선순위, 트랜잭션을 처리하려는 시도들이 실패한 경우에서의 재시도 횟수, 및 완료 기준들의 세트와 같은 부가적인 파라미터들을 또한 포함할 수 있다.
도 27의 단계(3)에서, DSLT-TF(1202) 기능을 호스팅하는 AE는, DSLT-MF(1204) 능력을 지원하는 IN-CSE(2702)에 DSLT 요청을 전송한다. 요청은, IN-CSE(2702)가 요청을 원자적 방식으로 구성원들에 배포함으로써 요청을 처리할 수 있도록, 단계(1)에서 생성된 그룹 리소스의 <transactionFanOutPoint> 자식 리소스에 전송된다. 이러한 요청은, 원엠투엠 비-차단 요청의 새로운 유형인 비-차단 트랜잭션 요청을 사용하여 전송될 수 있다. 이러한 요청에서, AE는, 비-차단 요청의 처리가 완료되었을 때 IN-CSE(2702)가 그에 통지할 때 사용하기를 원하는 통지 콜백 URI를 특정할 수 있다. 대안적으로, AE는 대신에 차단 요청을 사용할 수 있다.
도 27의 단계(4)에서, IN-CSE(2702)는 DSLT 요청을 수신한다. 요청이 비-차단 트랜잭션으로서 전송된 경우, IN-CSE(2702)는, 트랜잭션 지향 속성들을 지원하고 상태 속성을 "초기"로 구성하는 원엠투엠 <request> 리소스를 생성한다. 이러한 <request> 리소스는, DSLT를 처리하는 동안 DSLT 요청 리소스를 계속 추적하기 위해 IN-CSE(2702)에 의해 사용될 수 있다.
도 27의 단계(5)에서, IN-CSE(2702)는, 자신이 요청을 수신했고 그 요청을 처리하기 시작했다는 것을 표시하는 응답을 AE에 반환한다. 대안적으로, 요청은 차단 방식으로 처리될 수 있다.
이어서, 도 27의 단계(6)에서, IN-CSE(2702)는 그룹 트랜잭션 팬아웃 능력을 사용하여 DSLT를 처리한다.
도 27의 단계(7)에서, IN-CSE(2702)는, 그룹 구성원 리소스들이 IN-CSE(2702) 상에서 국부적으로 호스팅되지 않는다는 것을 검출한다. 그러므로, IN-CSE(2702)는 이러한 표적화된 디바이스들에 배포(즉, 팬아웃)하기 위해 대응하는 DSLT 요청들(즉, <contentInstance> 생성 프리미티브)을 준비한다. 이러한 DSLT는, 도 27에 도시된 바와 같이 비-차단 원엠투엠 <contentInstance> 생성 프리미티브로서 구조화될 수 있다. 대안적으로, 이러한 DSLT 요청은, 자신의 프리미티브 속성 내에 <contentInstance> 생성 프리미티브를 캡슐화하는 원엠투엠 <transaction> 생성 요청 프리미티브로서 구조화될 수 있다.
도 27의 단계(8)에서, ASN-CSE(2704 및 1206) 상의 DSLT-CF들(1208 및 1210)은 각각은 DSLT를 수신하여 <contentInstance>를 생성하고, 그들이 DSLT를 처리하는 동안 트랜잭션 상태를 계속 추적하기 위해 <request>(또는 대안적으로는 <transaction>) 리소스를 생성함으로써 요청을 처리한다. ASN-CSE들(2704 및 2706)은 DSLT에 포함된 트랜잭션 정보로 이러한 리소스의 상태를 구성한다. ASN-CSE들(2704 및 2706)은, 먼저, 표적화된 리소스(들)의 이용가능성을 확인함으로써, 트랜잭션을 처리하는 것을 시작한다. ASN-CSE들(2704 및 2706)은, 리소스의 특정된 동작을 수행하기 위한 이용가능성, 및 현재 리소스를 예비하고 잠근 다른 트랜잭션들이 존재하지 않는다는 것을 확인한다. 리소스가 이용가능한 경우, ASN-CSE들(2704 및 2706)은, 현재 트랜잭션의 처리 동안 도달할 수 있는 다른 트랜잭션들로부터의 간섭 없이 리소스 상에서 자신이 트랜잭션을 수행할 수 있도록 그 리소스를 잠근다.
도 27의 단계(9)에서, ASN-CSE들(2704 및 2706)은, DSLT가 수신되었고, 트랜잭션에 대해 처리가 시작되었고, 표적화된 리소스가 이용가능하고, 다른 트랜잭션들로부터의 간섭 없이 현재 트랜잭션이 진행될 수 있기 위해 리소스가 잠겼음을 표시하는 상태를 IN-CSE(2702)에 반환한다.
도 27의 단계(10)에서, IN-CSE(2702)는, 모든 구성원들이, 그들이 표적화된 리소스들을 성공적으로 잠갔음을 응답했다는 것을 검출한다. 결과적으로, IN-CSE(2702)는, 표적화된 구성원들에 트랜잭션을 실행할 것을 지시하도록 진행할 수 있다고 결정한다.
도 27의 단계(11)에서, IN-CSE(2702)는, 트랜잭션과 연관된 그의 대응하는 <request> 리소스의 명령 속성을 업데이트하기 위한 요청을 각각의 ASN-CSE(2704 및 2706)에 전송한다. 명령 속성은 "실행" 값으로 업데이트된다. 대안적으로, 이러한 명령 속성은 <transaction> 리소스의 속성일 수 있다.
도 27의 단계(12)에서, 트랜잭션을 실행하기 위한 명령을 수신할 시, 각각의 ASN-CSE(2704 및 2706)는 표적화된 리소스 상에서 트랜잭션에 특정된 동작을 수행한다.
도 27의 단계(13)에서, 일단 실행이 완료되면, 각각의 ASN-CSE(2704 및 2706)는 실행의 결과들 및 그것이 성공적이었는지 여부로 IN-CSE(2702)에 다시 응답한다.
도 27의 단계(14)에서, IN-CSE(2702)는, 모든 그룹 구성원들이, 그들이 표적화된 리소스들 상에서 트랜잭션을 성공적으로 실행했음을 응답했다는 것을 검출한다. 결과적으로, IN-CSE(2702)는, 결과들(예컨대, 업데이트된 리소스 표현)을 지속적이게 만들고 다른 트랜잭션들이 리소스 및 그 리소스의 업데이트된 상태에 액세스할 수 있게 하기 위해 리소스에 대한 잠금을 또한 해제함으로써, 결과들을 커밋할 것을 구성원들에 지시하도록 진행할 수 있다고 결정한다.
도 27의 단계(15)에서, IN-CSE(2702)는, 각각의 그룹 구성원에 트랜잭션을 커밋할 것을 명령하기 위한 요청을 전송한다. 이러한 명령은, IN-CSE(2702)가, 각각의 ASN-CSE(2704 및 2706)에 트랜잭션을 커밋할 것을 지시하는 각각의 ASN-CSE(2704 및 2706) 상에서 호스팅되는 <request>(또는 대안적으로, <transaction>) 리소스 내의 명령 속성을 업데이트하는 것에 의해 송출될 수 있다.
도 27의 단계(16)에서, 트랜잭션을 커밋하기 위한 명령을 수신할 시, 각각의 ASN-CSE(2704 및 2706)는, 트랜잭션을 실행할 때 이루어졌을 수 있는 리소스에 대한 임의의 업데이트들을 그 상태가 지속적이도록 저장한다. 이어서, ASN-CSE들(2704 및 2706)은 표적화된 리소스에 대한 임의의 잠금들을 해제한다.
도 27의 단계(17)에서, 일단 커밋이 완료되면, 각각의 ASN-CSE(2704 및 2706)는 커밋의 결과들 및 그것이 성공적이었는지 여부로 IN-CSE(2702)에 다시 응답한다.
도 27의 단계(18)에서, IN-CSE(2702)는, 모든 그룹 구성원들(즉, ASN-CSE(2704 및 2706) 둘 모두)이, 그들이 표적화된 리소스들 상에서 트랜잭션을 성공적으로 커밋했음을 응답했다는 것을 검출한다.
도 27의 단계(19)에서, IN-CSE(2702)는, AE로부터 자신이 수신한 DSLT에 대응하는 자신의 국부적으로 호스팅된 <request> 리소스를 업데이트한다. 이러한 업데이트에는, 트랜잭션들이 성공적이었는지 여부 및 성공적이지 않은 경우에는 실패에 대한 원인 또는 이유를 표시하는, 자신이 그룹 구성원들에 배포한 DSLT들 각각의 상태가 포함된다.
도 27의 단계(20)에서, 일단 DSLT 처리가 완료되면, IN-CSE(2702)는 AE에 통지할 수 있고, 이는 DSLT의 결과들을 포함한다. IN-CSE(2702)는, DSLT의 전체 상태뿐만 아니라, 개별 표적들 상에서 수행된 각각의 배포된 트랜잭션의 개별 상태를 포함할 수 있다. 이는, 실패들의 원인을 설명하는 오류 또는 디버그 정보를 포함할 수 있다. 이는, 기술자들 또는 운영자들이, 다른 DSLT를 송출하려 재시도하기 전에 문제들을 검출하고 장애가 있는 디바이스들을 교환하거나 복구할 수 있게 할 수 있다.
도 27의 단계(21)에서, 완료된 DSLT의 통지를 수신한 후에, AE는 자신이 통지를 수신했다는 확인으로 IN-CSE(2702)에 다시 응답할 수 있다.
도 27의 단계(22)에서, 임의의 시점에, AE가 DSLT 처리의 상태를 확인하기를 희망하는 경우, AE는 상태를 확인하기 위해 IN-CSE(2702)에 의해 호스팅되는 <request> 리소스에 질의할 수 있다. 질의 요청을 수신할 때, IN-CSE(2702)는, 자신이 이러한 리소스에 유지하는 DSLT의 상태를 확인할 수 있다.
도 27의 단계(23)에서, IN-CSE(2702)는, DSLT 처리의 상태를 AE에 반환한다.
원엠투엠 DSLT 시퀀스 절차
도 28은 원엠투엠 DSLT 시퀀싱 절차를 도시한다.
도 28의 단계(1)는 임의적이다. 도 28의 단계(1)에서, 하나 이상의 원엠투엠 DSLT 또는 DSLT 시퀀스 정책 리소스가 생성된다. 이러한 리소스들은 DSLT-TF(1202)를 호스팅하는 AE 또는 시스템 내의 다른 AE에 의해 생성될 수 있다. 각각의 정책 리소스는 IN-CSE(2702)에 의해 호스팅되는 DSLT-MF(1204)가 DSLT 시퀀스 요청들을 처리하는 방식을 제어하기 위한 하나 이상의 규칙을 포함할 수 있다. 이러한 규칙들은, DSLT 시퀀스 스케줄링, DSLT 시퀀스들의 재시도, DSLT 시퀀스들의 우선순위화, DSLT 시퀀스들에 대한 실행 및 완료 기준들에 관한 것일 수 있다. 대안적으로, IN-CSE(2702)에는 DSLT 시퀀스 정책들이 사전 프로비저닝될 수 있다.
도 28의 단계(2)에서, DSLT-TF(1202) 기능을 호스팅하는 AE는, ASN-CSE(2704 및 2706)에 의해 호스팅되는 컨테이너 리소스들 하에서 일련의 원엠투엠 <contentInstance>를 원자적으로 생성하기 위해 원엠투엠 DSLT 시퀀스 요청을 구축한다. 이러한 DSLT 시퀀스 요청은, 원엠투엠 <sequence> 생성 프리미티브로서 구조화될 수 있다. <sequence> 리소스는 일련의 <contentInstance> 생성 프리미티브들을 그의 트랜잭션들의 속성 내에 캡슐화할 수 있다. 각각의 <contentInstance> 생성 프리미티브는, ASN-CSE(2704 및 2706)에 의해 호스팅되는 컨테이너 리소스들이도록 구성될 자신의 구성원들의 속성을 갖는 IN-CSE(2702) 상에서 호스팅되는 그룹 리소스를 표적화할 수 있다. 따라서, 각각의 <contentInstance> 생성 프리미티브는 시퀀스 내의 별개의 트랜잭션이다. 도 27에 도시되진 않지만, 개별 <contentInstance> 생성 프리미티브들은 대신에 IN-CSE(2702) 상의 별개의 <transaction> 리소스들로서 생성될 수 있다. <sequence> 리소스의 트랜잭션들의 속성은 이러한 개별 <transaction> 리소스들을 참조하는 식별자들의 목록으로 구성될 수 있다. <sequence> 생성 프리미티브는 또한, 시퀀스를 수행할 때의 스케줄, 실행 기준들의 세트, 우선순위, 시퀀스를 처리하려는 시도들이 실패한 경우에서의 재시도 횟수, 및 완료 기준들의 세트와 같은 부가적인 파라미터들을 또한 포함할 수 있다.
도 28의 단계(3)에서, DSLT-TF(1202) 기능을 호스팅하는 AE는, DSLT-MF(1204) 능력을 지원하는 IN-CSE(2702)에 DSLT 시퀀스 요청을 전송한다. 이러한 요청은, 차단 또는 비-차단 요청을 사용하여 IN-CSE(2702)에 전송될 수 있다. 비-차단이 사용되는 경우, AE는, 비-차단 요청의 처리가 완료되었을 때 IN-CSE(2702)가 그에 통지할 때 사용하기를 원하는 통지 콜백 URI를 특정할 수 있다. 대안적으로, AE는 대신에, 차단 요청, 또는 기존 원엠투엠 비-차단 요청들 중 하나를 사용할 수 있다.
도 28의 단계(4)에서, IN-CSE(2702)는 DSLT 시퀀스 요청을 수신한다.
도 28의 단계(5)에서, IN-CSE(2702)는, 자신이 요청을 수신했고 그 요청을 처리하기 시작했다는 것을 표시하는 응답을 AE에 반환한다. 대안적으로, 요청은 차단 방식으로 처리될 수 있다. 도면에 도시되진 않지만, AE는, <sequence>에 대한 변경들(예컨대, 시퀀스의 상태에 대한 업데이트들)이 발생할 때 IN-CSE(2702)로부터 통지들을 수신하기 위해, <sequence> 리소스에 대한 가입을 생성할 수 있다.
이어서, 도 28의 단계(6)에서, IN-CSE(2702)는 DSLT 시퀀스를 처리하는 것을 시작한다.
도 28의 단계(7)에서, IN-CSE(2702)는 시퀀스 내의 제1 DSLT를 획득하기 위한 요청을 파싱한다. IN-CSE(2702)는, 이러한 DSLT가 ASN-CSE(2704 및 2706) 상에서 호스팅되는 컨테이너들인 구성원 리소스들로 이루어지는 그룹 리소스를 표적화함을 검출한다. 그러므로, IN-CSE(2702)는 이러한 표적화된 디바이스들에 배포(즉, 팬아웃)하기 위해 대응하는 DSLT 요청들(즉, <contentInstance> 생성 프리미티브)을 준비한다. 이러한 DSLT는, 도 27에 도시된 바와 같이 비-차단 원엠투엠 <contentInstance> 생성 프리미티브로서 구조화될 수 있다. 대안적으로, 이러한 DSLT 요청은, 자신의 프리미티브 속성 내에 <contentInstance> 생성 프리미티브를 캡슐화하는 원엠투엠 <transaction> 생성 요청 프리미티브로서 구조화될 수 있다.
도 28의 단계(8)에서, IoT 디바이스(1234 및 1236) 상의 DSLT-CF들(1208 및 1210) 각각이 그들의 DSLT-REQ들을 수신한다. 둘 모두는 요청을 처리하고, 그들이 DSLT를 처리하는 동안 트랜잭션 상태를 계속 추적하기 위해 국부적 DSLT 리소스를 생성한다. DSLT-CF들은 그들의 리소스들의 속성들을 DSLT-REQ 파라미터들에 포함된 정보로 구성한다. DSLT-CF들은, 먼저, 표적화된 리소스(들)의 이용가능성을 확인함으로써, 트랜잭션을 처리하는 것을 시작한다. 리소스(들)가 IoT 디바이스에 국부적인 경우, DSLT-CF(1210)는, 리소스의 특정된 동작을 수행하기 위한 이용가능성, 및 현재 리소스를 예비하고 잠근 다른 트랜잭션들이 존재하지 않는다는 것을 확인한다. 리소스가 이용가능한 경우, DSLT-CF는, 현재 트랜잭션의 처리 동안 도달할 수 있는 다른 트랜잭션들로부터의 간섭 없이 리소스 상에서 자신이 트랜잭션을 수행할 수 있도록 그 리소스를 잠글 수 있다. DSLT-CF(12210)가 DSLT-REQ를 수신하고 요청이 국부적 디바이스 상에서 호스팅되지 않는 리소스를 표적화하는 것을 발견한 경우에서, DSLT-CF는 (가능하게는, 디바이스 상에서 국부적으로 호스팅되는 DSLT-MF(1204)의 보조로) 다른 디바이스 상의 DSLT-CF(1208)가 그것을 처리할 수 있도록 시스템 내의 다른 디바이스에 DSLT-REQ를 재표적화할 수 있다.
ASN-CSE(2704 및 2706) 상의 DSLT-CF들은 각각은 DSLT를 수신하여 <contentInstance>를 생성하고, 그들이 DSLT를 처리하는 동안 트랜잭션 상태를 계속 추적하기 위해 <request>(또는 대안적으로는 <transaction>) 리소스를 생성함으로써 요청을 처리한다. ASN-CSE들(2704 및 2706)은 DSLT에 포함된 트랜잭션 정보로 이러한 리소스의 상태를 구성한다. ASN-CSE들(2704 및 2706)은, 먼저, 표적화된 리소스(들)의 이용가능성을 확인함으로써, 트랜잭션을 처리하는 것을 시작한다. ASN-CSE들(2704 및 2706)은, 리소스의 특정된 동작을 수행하기 위한 이용가능성, 및 현재 리소스를 예비하고 잠근 다른 트랜잭션들이 존재하지 않는다는 것을 확인한다. 리소스가 이용가능한 경우, ASN-CSE들(2704 및 2706)은, 현재 트랜잭션의 처리 동안 도달할 수 있는 다른 트랜잭션들로부터의 간섭 없이 리소스 상에서 자신이 트랜잭션을 수행할 수 있도록 그 리소스를 잠근다.
도 28의 단계(9)에서, ASN-CSE들(2704 및 2706)은, DSLT가 수신되었고, 트랜잭션에 대해 처리가 시작되었고, 표적화된 리소스가 이용가능하고, 다른 트랜잭션들로부터의 간섭 없이 현재 트랜잭션이 진행될 수 있기 위해 리소스가 잠겼음을 표시하는 상태를 IN-CSE(2702)에 반환한다.
도 28의 단계(10)에서, IN-CSE(2702)는, 모든 구성원들이, 그들이 표적화된 리소스들을 성공적으로 잠갔음을 응답했다는 것을 검출한다. 결과적으로, IN-CSE(2702)는, 표적화된 구성원들에 트랜잭션을 실행할 것을 지시하도록 진행할 수 있다고 결정한다.
도 28의 단계(11)에서, IN-CSE(2702)는, 트랜잭션과 연관된 그의 대응하는 <request> 리소스의 명령 속성을 업데이트하기 위한 요청을 각각의 ASN-CSE에 전송한다. 명령 속성은 "실행" 값으로 업데이트된다. 대안적으로, 이러한 명령 속성은 <transaction> 리소스의 속성일 수 있다.
도 28의 단계(12)에서, 트랜잭션을 실행하기 위한 명령을 수신할 시, 각각의 ASN-CSE(2704 및 2706)는 표적화된 리소스 상에서 트랜잭션에 특정된 동작을 수행한다.
도 28의 단계(13)에서, 일단 실행이 완료되면, 각각의 ASN-CSE(2704 및 2706)는 실행의 결과들 및 그것이 성공적이었는지 여부로 IN-CSE(2702)에 다시 응답한다.
도 28의 단계(14)에서, IN-CSE(2702)는, 모든 표적화된 구성원들(즉, ASN-CSE(2704 및 2706))이, 그들이 표적화된 리소스들 상에서 트랜잭션을 성공적으로 실행했음을 응답했다는 것을 검출한다. 그런 다음, IN-CSE(2702)는, 시퀀스 내에 임의의 잔여 DSLT들이 존재하는지 여부를 확인한다. 존재하는 경우, IN-CSE(2702)는 다음 DSLT를 준비하고 단계들(7-14)을 반복한다. 시퀀스 내에 잔여 DSLT들이 존재하지 않는 경우, IN-CSE(2702)는, 시퀀스의 일부로서 처리된 모든 DSLT들의 결과들을 지속적이게 만들고 다른 트랜잭션들이 리소스 및 그 리소스의 업데이트된 상태에 액세스할 수 있게 하기 위해 리소스에 대한 잠금을 또한 해제함으로써, 결과들을 커밋할 것을 구성원들에 지시하도록 진행할 수 있다고 결정한다.
도 28의 단계(15)에서, IN-CSE(2702)는, 실행된 각각의 DSLT에 대한 ASN-CSE(2704 및 2706)에 일련의 커밋 요청들을 전송한다. 각각의 명령은, IN-CSE(2702)가, 각각의 ASN-CSE(2704 및 2706)에 대응하는 트랜잭션을 커밋할 것을 지시하는 각각의 ASN-CSE(2704 및 2706) 상에서 호스팅되는 <request>(또는 대안적으로, <transaction>) 리소스 내의 명령 속성을 업데이트하는 것에 의해 송출될 수 있다.
도 28의 단계(16)에서, 주어진 DSLT를 커밋하기 위한 각각의 명령을 수신할 시, 각각의 ASN-CSE(2704 및 2706)는, 트랜잭션을 실행할 때 이루어졌을 수 있는 리소스에 대한 임의의 업데이트들을 그 상태가 지속적이도록 저장한다. 커밋된 리소스의 상태에 대한 임의의 업데이트들에 기반하여, 각각의 ASN-CSE(2704 및 2706)는 또한, 업데이트된 상태에 관한 통지들을, 표적화된 리소스에 가입했을 수 있는 시스템 내의 임의의 다른 엔티티들에 전송할 수 있다. 그런 다음, 각각의 ASN-CSE(2704 및 2706)는 표적화된 리소스에 대한 임의의 잠금들을 해제하고, 임의의 저장된 동작 전 상태를 삭제할 수 있다.
도 28의 단계(17)에서, 일단 각각의 커밋이 완료되면, 각각의 ASN-CSE(2704 및 2706)는 커밋의 결과들 및 그것이 성공적이었는지 여부로 IN-CSE(2702)에 다시 응답한다.
도 28의 단계(18)에서, IN-CSE(2702)는, 표적화된 ASN-CSE들(2704 및 2706) 각각이, 그들이 개개의 표적화된 리소스들 상에서 시퀀스 내의 모든 트랜잭션들을 성공적으로 커밋했음을 응답했다는 것을 검출한다.
도 28의 단계(19)에서, IN-CSE(2702)는 자신의 국부적으로 호스팅된 DSLT 시퀀스 리소스를 업데이트한다. 이러한 업데이트에는, 시퀀스 내의 그리고 자신이 배포한 DSLT들 각각의 상태가 포함된다. 이러한 상태는, 트랜잭션 시퀀스가 성공적이었는지 여부 및 성공적이지 않은 경우에는 실패에 대한 이유를 표시한다. IN-CSE(2702)는 또한, 시퀀스 내의 임의의 실패한 DSLT들에 대한 개별 상태 및 실패 정보를 포함할 수 있다.
도 28의 단계(20)에서, 일단 DSLT 시퀀스 처리가 완료되면, IN-CSE(2702)는 AE에 통지할 수 있고, 이는 DSLT 시퀀스의 결과들을 포함한다. IN-CSE(2702)는, DSLT 시퀀스의 전체 상태뿐만 아니라, 개별 표적들 상에서 수행된 시퀀스 내의 각각의 배포된 트랜잭션의 개별 상태를 포함할 수 있다. 이는, 실패들의 원인을 설명하는 오류 또는 디버그 정보를 포함할 수 있다. 이는, 기술자들 또는 운영자들이, 다른 DSLT를 송출하려 재시도하기 전에 문제들을 검출하고 장애가 있는 디바이스들을 교환하거나 복구할 수 있게 할 수 있다.
도 28의 단계(21)에서, 완료된 DSLT 시퀀스의 통지를 수신한 후에, AE는 자신이 통지를 수신했다는 확인으로 IN-CSE(2702)에 다시 응답할 수 있다.
도 28의 단계(22)에서, 임의의 시점에, AE가 DSLT 시퀀스 처리의 상태를 확인하기를 희망하는 경우, AE는 상태를 확인하기 위해 IN-CSE(2702)에 질의할 수 있다. 질의 요청을 수신할 때, IN-CSE(2702)는, 자신이 대응하는 DSLT 시퀀스 리소스에 유지하는 DSLT 시퀀스 리소스의 상태를 확인할 수 있다.
도 28의 단계(23)에서, DSLT-MF(1204)는, DLTS 상태 질의를 개시한 DSLT-TF(1202)에 DSLT 시퀀스 처리의 상태를 반환한다.
분산형 서비스 계층 트랜잭션 사용자 인터페이스
사용자가 분산형 트랜잭션 관리와 관련된 기능들을 제어 및/또는 구성하는 것을 보조하기 위해 그래픽 사용자 인터페이스(GUI)들과 같은 인터페이스들이 사용될 수 있다. 사용자 인터페이스, 이를테면 도 29에 도시된 바와 같은 인터페이스들(2902, 2904, 2906 및 2908)은, 요청이 원자적 방식으로 수행될 수 있도록 사용자가 DSLT 기반 요청을 다수의 IoT 디바이스들에 개시할 수 있게 구현될 수 있다. 예컨대, 조립 라인 배치와 같은 조정된 방식으로 동작하는 디바이스들의 세트에 대한 제어 설정들의 원자적 업데이트를 수행하도록 이루어진다. 사용자 인터페이스는 또한, 디바이스들, 게이트웨이들, 서버들, 및 애플리케이션들 내의 DSLT 관련 정책들을 구성하여 그들이 수신하는 DSLT들을 그들이 처리하는 방식을 제어하도록 구현될 수 있다. 인터페이스(2902, 2904, 2906 및 2908)는 아래에서 설명된 도 30c-d에 도시된 것들과 같은 디스플레이들을 사용하여 생성될 수 있다는 것이 이해되어야 한다.
예시적인 M2M/IoT/WoT 통신 시스템
본원에서 설명되는 다양한 기법들은 하드웨어, 펌웨어, 소프트웨어, 또는 적절한 경우에는 이들의 조합들과 관련하여 구현될 수 있다. 그러한 하드웨어, 펌웨어, 및 소프트웨어는 통신 네트워크의 다양한 노드들에 위치된 장치들에 상주할 수 있다. 장치들은 본원에서 설명된 방법들을 수행하기 위해 단독으로 또는 서로 조합되어 동작할 수 있다. 본원에서 사용되는 바와 같이, "장치", "네트워크 장치", "노드", "디바이스", 및 "네트워크 노드"라는 용어들은 상호교환가능하게 사용될 수 있다.
서비스 계층은 네트워크 서비스 아키텍처 내의 기능적 계층일 수 있다. 서비스 계층들은 전형적으로 HTTP, CoAP 또는 MQTT와 같은 애플리케이션 프로토콜 계층 위에 위치되며, 클라이언트 애플리케이션들에 부가 가치 서비스들을 제공한다. 서비스 계층은 또한, 예컨대, 제어 계층 및 전송/액세스 계층과 같은 하위 리소스 계층에서 코어 네트워크들에 인터페이스를 제공한다. 서비스 계층은 서비스 정의, 서비스 런타임 인에이블먼트(enablement), 정책 관리, 액세스 제어, 및 서비스 클러스터링을 포함하는 다수의 카테고리들의 (서비스) 능력들 또는 기능성들을 지원한다. 최근에, 몇몇 산업 표준 기구들, 예컨대, 원엠투엠이 M2M 유형들의 디바이스들 및 애플리케이션들을 인터넷/웹, 셀룰러, 기업, 및 홈 네트워크들과 같은 배치들로 통합하는 것과 연관된 난제들을 해결하기 위한 M2M 서비스 계층들을 개발해왔다. M2M 서비스 계층은 애플리케이션들 및/또는 다양한 디바이스들에 CSE 또는 SCL로 지칭될 수 있는, 서비스 계층에 의해 지원되는 위에서 언급된 능력들 또는 기능성들의 집합 또는 세트에 대한 액세스를 제공할 수 있다. 몇몇 예들은 다양한 애플리케이션들에 의해 공통으로 사용될 수 있는, 보안, 과금, 데이터 관리, 디바이스 관리, 발견, 프로비저닝, 및 연결성 관리를 포함하지만 이에 제한되지 않는다. 이러한 능력들 및 기능성들은 M2M 서비스 계층에 의해 정의된 메시지 포맷들, 리소스 구조들 및 리소스 표현들을 이용하는 API들을 통해 그러한 다양한 애플리케이션들에 이용가능해진다. CSE 또는 SCL은, 하드웨어 및/또는 소프트웨어에 의해 구현될 수 있고, 다양한 애플리케이션들 및/또는 디바이스들(즉, 그러한 기능적 엔티티들 사이의 기능적 인터페이스들)에 노출되는 (서비스) 능력들 또는 기능성들을 이들이 그러한 능력들 또는 기능성들을 사용하도록 제공하는 기능적 엔티티이다.
도 30a는 하나 이상의 개시된 실시예들이 구현될 수 있는 예시적인 머신-투-머신(M2M), 사물 인터넷(IoT), 또는 사물 웹(WoT) 통신 시스템(10)의 도면이다. 일반적으로, M2M 기술들은 IoT/WoT에 대한 빌딩 블록들을 제공하며, 임의의 M2M 디바이스, M2M 게이트웨이, M2M 서버, 또는 M2M 서비스 플랫폼은 IoT/WoT뿐만 아니라 IoT/WoT 서비스 계층 등의 구성요소 또는 노드일 수 있다. 통신 시스템(10)은 개시된 실시예들의 기능성을 구현하는데 사용될 수 있고, 기능성 및 논리 엔티티들, 이를테면, DSLT-TF(1202); DSLT-MF(1204 및 1206); DSLT-CF(1208, 1210, 1212, 및 1214); DSLT-MF API(1302); DSLT-MF 처리(1304); DSLT-MF 시퀀스 처리(1306); DSLT-MF 정책 엔진(1308); DSLT-MF 스케줄러(1310); DSLT-CF API(1402); DSLT-CF 처리(1404); DSLT-CF 시퀀스 처리(1406); DSLT-MF CSF(2304); 서비스 계층(102); 애플리케이션 프로토콜들(104); 애플리케이션들(106); CSE(302, 306, 306 및 2302); AE(304, 704, 706, 708 및 2306), NSE(308), IoT 애플리케이션(1002 및 1230), IoT 디바이스(1004, 1006, 1008, 1234, 1236, 1238 및 1240); IoT 서버(1102 및 1232); IoT 게이트웨이(1242); IN-CSE(2702); ASN-CSE(2704 및 2706) 및 인터페이스들(2902, 2904, 2906 및 2908)과 같은 인터페이스들을 생성하기 위한 논리 엔티티들을 포함할 수 있다.
도 30a에 도시된 바와 같이, M2M/IoT/WoT 통신 시스템(10)은 통신 네트워크(12)를 포함한다. 통신 네트워크(12)는 고정 네트워크(예컨대, 이더넷, 파이버(Fiber), ISDN, PLC 등) 또는 무선 네트워크(예컨대, WLAN, 셀룰러 등) 또는 이종 네트워크들의 네트워크일 수 있다. 예컨대, 통신 네트워크(12)는 음성, 데이터, 비디오, 메시징, 브로드캐스트 등과 같은 콘텐츠를 다수의 사용자들에게 제공하는 다수의 액세스 네트워크들로 구성될 수 있다. 예컨대, 통신 네트워크(12)는 코드 분할 다중 액세스(CDMA), 시분할 다중 액세스(TDMA), 주파수 분할 다중 액세스(FDMA), 직교 FDMA(OFDMA), 단일-캐리어 FDMA(SC-FDMA) 등과 같은 하나 이상의 채널 액세스 방법을 이용할 수 있다. 추가로, 통신 네트워크(12)는, 예컨대, 코어 네트워크, 인터넷, 센서 네트워크, 산업 제어 네트워크, 개인 영역 네트워크, 융합형 개인 네트워크, 위성 네트워크, 홈 네트워크, 또는 기업 네트워크와 같은 다른 네트워크들을 포함할 수 있다.
도 30a에 도시된 바와 같이, 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(예컨대, 지그비(Zigbee), 6LoWPAN, 블루투스), 직접 무선 링크, 및 유선을 포함하는 다양한 네트워크들을 통해 통신할 수 있다.
예시적인 M2M 단말 디바이스들(18)은, 태블릿, 스마트 폰들, 의료 디바이스들, 온도 및 날씨 모니터들, 커넥티드 카(connected car)들, 스마트 미터들, 게임 콘솔들, 개인 휴대 정보 단말기들, 건강 및 보건 모니터들, 조명들, 온도조절기들, 가전들, 차고 문들 및 다른 액추에이터 기반 디바이스들, 보안 디바이스들, 및 스마트 아웃렛(smart outlet)들을 포함하지만 이에 제한되지 않는다.
도 30b를 참조하면, M2M 애플리케이션(20), M2M 게이트웨이 디바이스들(14), 및 M2M 단말 디바이스들(18)과 통신 네트워크(12)에 대한 서비스들을 제공하는 필드 도메인에서의 M2M 서비스 계층(22)이 예시된다. M2M 서비스 계층(22)은, 예컨대, 아래에 설명되는 도 30c 및 도 30d에 예시된 디바이스들을 포함하는, 하나 이상의 서버, 컴퓨터, 디바이스, 가상 머신(예컨대, 클라우드/스토리지 팜들(cloud/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')은, 서버들, 컴퓨터들, 디바이스들, 가상 머신들(예컨대, 클라우드 컴퓨팅/스토리지 팜들 등) 등을 포함할 수 있는 네트워크의 하나 이상의 노드에 의해 구현될 수 있다.
또한 도 30b를 참조하면, M2M 서비스 계층들(22 및 22')은 다양한 애플리케이션들 및 버티컬들이 활용할 수 있는 서비스 전달 능력들의 코어 세트를 제공한다. 이러한 서비스 능력들은 M2M 애플리케이션들(20 및 20')이 디바이스들과 상호작용하고 데이터 수집, 데이터 분석, 디바이스 관리, 보안, 청구서 발부, 서비스/디바이스 발견 등과 같은 기능들을 수행할 수 있게 한다. 기본적으로, 이러한 서비스 능력들은 애플리케이션들로부터 이러한 기능성들을 구현하는 부담을 덜어주고, 따라서, 애플리케이션 개발이 단순화되고 출시까지의 비용 및 시간이 감소된다. 서비스 계층들(22 및 22')은 또한 서비스 계층들(22 및 22')이 제공하는 서비스들과 관련하여 네트워크들(12)을 통해 M2M 애플리케이션들(20 및 20')이 통신할 수 있게 한다.
본 출원의 방법들은 서비스 계층(22 및 22')의 일부로서 구현될 수 있다. 서비스 계층(22 및 22')은, 애플리케이션 프로그래밍 인터페이스(API)들과 기본 네트워킹 인터페이스들의 세트를 통해 부가 가치 서비스 능력들을 지원하는 소프트웨어 미들웨어 계층이다. ETSI M2M 및 원엠투엠 둘 모두는 본 출원의 연결 방법들을 포함할 수 있는 서비스 계층을 사용한다. ETSI M2M의 서비스 계층은 서비스 능력 계층(SCL)으로 지칭된다. SCL은, M2M 디바이스 내에서(이 경우에, SCL은 디바이스 SCL(DSCL)로 지칭됨), 게이트웨이 내에서(이 경우에, SCL은 게이트웨이 SCL(GSCL)로 지칭됨), 및/또는 네트워크 노드 내에서(이 경우에, SCL은 네트워크 SCL(NSCL)로 지칭됨) 구현될 수 있다. 원엠투엠 서비스 계층은 한 세트의 공통 서비스 기능(CSF)들(즉, 서비스 능력들)을 지원한다. 하나 이상의 특정 유형의 CSF들의 세트의 인스턴스화는 공통 서비스 엔티티(CSE)로 지칭되며, 이는, 상이한 유형들의 네트워크 노드들(예컨대, 기반구조 노드, 중간 노드, 애플리케이션 특정 노드) 상에서 호스팅될 수 있다. 추가로, 본 출원의 연결 방법들은 본 출원의 연결 방법들과 같은 서비스들에 액세스하기 위해 서비스 지향 아키텍처(SOA) 및/또는 리소스 지향 아키텍처(ROA)를 사용하는 M2M 네트워크의 일부로서 구현될 수 있다.
일부 실시예들에서, M2M 애플리케이션들(20 및 20')은 개시된 시스템들 및 방법들과 함께 사용될 수 있다. M2M 애플리케이션들(20 및 20')은 UE 또는 게이트웨이와 상호작용하는 애플리케이션들을 포함할 수 있고, 또한, 다른 개시된 시스템들 및 방법들과 함께 사용될 수 있다.
일 실시예에서, 논리 엔티티들, 이를테면, DSLT-TF(1202); DSLT-MF(1204 및 1206); DSLT-CF(1208, 1210, 1212, 및 1214); DSLT-MF API(1302); DSLT-MF 처리(1304); DSLT-MF 시퀀스 처리(1306); DSLT-MF 정책 엔진(1308); DSLT-MF 스케줄러(1310); DSLT-CF API(1402); DSLT-CF 처리(1404); DSLT-CF 시퀀스 처리(1406); DSLT-MF CSF(2304); 서비스 계층(102); CSE(302, 306, 306 및 2302); NSE(308); IoT 서버(1102 및 1232), IoT 게이트웨이(1242); IN-CSE(2702); ASN-CSE(2704 및 2706)는, 도 30b에 도시된 바와 같이, M2M 서버, M2M 게이트웨이, 또는 M2M 디바이스와 같은 M2M 노드에 의해 호스팅되는 M2M 서비스 계층 인스턴스 내에서 호스팅될 수 있다. 예컨대, 이러한 논리 엔티티들은 M2M 서비스 계층 인스턴스 내의 개별 서비스 능력을 포함하거나 기존 서비스 능력 내의 하위 기능으로서 이루어질 수 있다.
M2M 애플리케이션들(20 및 20')은 운송, 건강 및 웰니스, 커넥티드 홈, 에너지 관리, 자산 추적, 및 보안과 감시와 같은(이에 제한되지 않음) 다양한 산업들에서의 애플리케이션들을 포함할 수 있다. 위에 언급된 바와 같이, 시스템의 디바이스들, 게이트웨이들, 서버들 및 다른 노드들에 걸쳐 실행되는 M2M 서비스 계층은, 예컨대, 데이터 수집, 디바이스 관리, 보안, 청구서 발부, 위치 추적/지오펜싱(geofencing), 디바이스/서비스 발견, 및 레거시 시스템 통합과 같은 기능들을 지원하고, 이러한 기능들을 서비스들로서 M2M 애플리케이션들(20 및 20')에 제공한다.
일반적으로, 서비스 계층들(22 및 22')은, 애플리케이션 프로그래밍 인터페이스(API)들과 기본 네트워킹 인터페이스들의 세트를 통해 부가 가치 서비스 능력들을 지원하는 소프트웨어 미들웨어 계층을 정의한다. ETSI M2M 및 원엠투엠 아키텍처들 둘 모두는 서비스 계층을 정의한다. ETSI M2M의 서비스 계층은 서비스 능력 계층(SCL)으로 지칭된다. SCL은 ETSI M2M 아키텍처의 다양한 상이한 노드들에서 구현될 수 있다. 예컨대, 서비스 계층의 인스턴스는, M2M 디바이스 내에서(이 경우에, SCL은 디바이스 SCL(DSCL)로 지칭됨), 게이트웨이 내에서(이 경우에, SCL은 게이트웨이 SCL(GSCL)로 지칭됨), 및/또는 네트워크 노드 내에서(이 경우에, SCL은 네트워크 SCL(NSCL)로 지칭됨) 구현될 수 있다. 원엠투엠 서비스 계층은 한 세트의 공통 서비스 기능(CSF)들(즉, 서비스 능력들)을 지원한다. 하나 이상의 특정 유형의 CSF들의 세트의 인스턴스화는 공통 서비스 엔티티(CSE)로 지칭되며, 이는, 상이한 유형들의 네트워크 노드들(예컨대, 기반구조 노드, 중간 노드, 애플리케이션 특정 노드) 상에서 호스팅될 수 있다. 3세대 파트너쉽 프로젝트(3GPP)는 또한 머신 유형 통신들(MTC)에 대한 아키텍처를 정의하였다. 그 아키텍처에서, 서비스 계층, 및 서비스 계층이 제공하는 서비스 능력들은 서비스 능력 서버(SCS)의 일부로서 구현된다. ETSI M2M 아키텍처의 DSCL, GSCL, 또는 NSCL에, 3GPP MTC 아키텍처의 서비스 능력 서버(SCS)에, 원엠투엠 아키텍처의 CSF 또는 CSE에, 또는 네트워크의 어떤 다른 노드에 구현되든 간에, 서비스 계층의 인스턴스는, 서버들, 컴퓨터들, 및 다른 컴퓨팅 디바이스들 또는 노드들을 포함하는, 네트워크 내의 하나 이상의 독립형 노드 상에서 실행되는 논리 엔티티(예컨대, 소프트웨어, 컴퓨터 실행가능 명령어들 등)로서 또는 하나 이상의 기존 노드의 일부로서 구현될 수 있다. 예로서, 서비스 계층 또는 그의 구성요소의 인스턴스는, 아래에서 설명되는 도 30c 또는 도 30d에 예시된 일반적인 아키텍처를 갖는 네트워크 노드(예컨대, 서버, 컴퓨터, 게이트웨이, 디바이스 등) 상에서 실행되는 소프트웨어의 형태로 구현될 수 있다.
추가로, 본원에서 설명되고 도면들에서 예시되는 논리 엔티티들은 본 출원의 서비스들에 액세스하기 위해 서비스 지향 아키텍처(SOA) 및/또는 리소스 지향 아키텍처(ROA)를 사용하는 M2M 네트워크의 일부로서 구현될 수 있다.
도 30c는 M2M 디바이스(18), M2M 게이트웨이(14), M2M 서버(22) 등과 같은 네트워크 장치(30)의 예시적인 하드웨어/소프트웨어 아키텍처의 블록도이다. 장치(30)의 아키텍처는 본원에서 설명되고 도면들에서 예시되는 전술한 논리 엔티티들 중 임의의 것을 구현하는 데 사용될 수 있다. 장치(30)는 도 30a-b에 도시된 바와 같은 M2M 네트워크의 일부 또는 비-M2M 네트워크의 일부일 수 있다. 도 30c에 도시된 바와 같이, 장치(30)는 프로세서(32), 비-착탈식 메모리(44), 착탈식 메모리(46), 스피커/마이크로폰(38), 키패드(40), 디스플레이, 터치패드, 및/또는 표시기들(42), 전원(48), 위성 항법 시스템(GPS) 칩셋(50), 및 다른 주변기기들(52)을 포함할 수 있다. 장치(30)는 또한, 송수신기(34) 및 송신/수신 요소(36)와 같은 통신 회로를 포함할 수 있다. 장치(30)는, 실시예와 일관성을 유지하면서 전술된 요소들의 임의의 하위 조합을 포함할 수 있다는 것이 인식될 것이다. 이러한 장치는 본원에서 설명된 기능성을 구현하는 노드일 수 있다.
프로세서(32)는 범용 프로세서, 특수 목적 프로세서, 종래 프로세서, 디지털 신호 프로세서(DSP), 복수의 마이크로프로세서들, DSP 코어와 연관된 하나 이상의 마이크로프로세서, 제어기, 마이크로제어기, 주문형 집적 회로(ASIC)들, 필드 프로그래밍가능 게이트 어레이(FPGA) 회로들, 임의의 다른 유형의 집적 회로(IC), 상태 머신 등일 수 있다. 일반적으로, 프로세서(32)는 장치의 다양한 요구되는 기능들을 수행하기 위해 장치의 메모리(예컨대, 메모리(44) 및/또는 메모리(46))에 저장되는 컴퓨터 실행가능 명령어들을 실행할 수 있다. 예컨대, 프로세서(32)는 신호 코딩, 데이터 처리, 전력 제어, 입력/출력 처리, 및/또는 장치(30)가 무선 또는 유선 환경에서 동작할 수 있게 하는 임의의 다른 기능성을 수행할 수 있다. 프로세서(32)는 애플리케이션 계층 프로그램들(예컨대, 브라우저들) 및/또는 무선 액세스 계층(RAN) 프로그램들 및/또는 다른 통신 프로그램들을 실행할 수 있다. 프로세서(32)는 또한, 예컨대, 이를테면 액세스 계층 및/또는 애플리케이션 계층에서, 인증, 보안 키 협의, 및/또는 암호화 동작들과 같은 보안 동작들을 수행할 수 있다.
도 30c에 도시된 바와 같이, 프로세서(32)는 자신의 통신 회로(예컨대, 송수신기(34) 및 송신/수신 요소(36))에 결합된다. 프로세서(32)는, 컴퓨터 실행가능 명령어들의 실행을 통해, 장치(30)로 하여금 그 장치가 연결되는 네트워크를 통해 다른 네트워크 장치들과 통신하게 하기 위해 통신 회로를 제어할 수 있다. 특히, 프로세서(32)는 본원에서 그리고 청구항들에서 설명된 송신 및 수신 단계들을 수행하기 위해 통신 회로를 제어할 수 있다. 도 30c는 프로세서(32) 및 송수신기(34)를 별개의 구성요소들로서 도시하지만, 프로세서(32) 및 송수신기(34)는 전자 패키지 또는 칩에 함께 통합될 수 있다는 것이 인식될 것이다.
송신/수신 요소(36)는, M2M 서버들, 게이트웨이들, 디바이스 등을 포함하는 다른 장치들에 신호들을 송신하거나 그로부터 신호를 수신하도록 구성될 수 있다. 예컨대, 실시예에서, 송신/수신 요소(36)는 RF 신호들을 송신 및/또는 수신하도록 구성되는 안테나일 수 있다. 송신/수신 요소(36)는 다양한 네트워크들 및 에어 인터페이스들, 이를테면, WLAN, WPAN, 셀룰러 등을 지원할 수 있다. 실시예에서, 송신/수신 요소(36)는, 예컨대, IR, UV, 또는 가시광 신호들을 송신 및/또는 수신하도록 구성되는 방출기/검출기일 수 있다. 또 다른 실시예에서, 송신/수신 요소(36)는 RF 신호 및 광 신호들 둘 모두를 송신 및 수신하도록 구성될 수 있다. 송신/수신 요소(36)는 무선 또는 유선 신호들의 임의의 조합을 송신 및/또는 수신하도록 구성될 수 있다는 것이 인식될 것이다.
게다가, 송신/수신 요소(36)가 단일 요소로서 도 30c에 도시되지만, 장치(30)는 임의의 수의 송신/수신 요소(36)를 포함할 수 있다. 더 구체적으로, 장치(30)는 MIMO 기술을 이용할 수 있다. 따라서, 실시예에서, 장치(30)는 무선 신호들을 송신 및 수신하기 위한 2개 이상의 송신/수신 요소(36)(예컨대, 다수의 안테나들)를 포함할 수 있다.
송수신기(34)는 송신/수신 요소(36)에 의해 송신될 신호들을 변조하고, 송신/수신 요소(36)에 의해 수신되는 신호들을 복조하도록 구성될 수 있다. 위에 언급된 바와 같이, 장치(30)는 다중 모드 능력들을 가질 수 있다. 따라서, 송수신기(34)는, 장치(30)가, 예컨대, UTRA 및 IEEE 802.11과 같은 다수의 RAT들을 통해 통신할 수 있게 하기 위한 다수의 송수신기들을 포함할 수 있다.
프로세서(32)는 비-착탈식 메모리(44) 및/또는 착탈식 메모리(46)와 같은 임의의 유형의 적합한 메모리로부터 정보에 액세스하거나 그 메모리에 데이터를 저장할 수 있다. 예컨대, 프로세서(32)는 위에 설명된 바와 같이, 자신의 메모리에 세션 컨텍스트(session context)를 저장할 수 있다. 비-착탈식 메모리(44)는 랜덤 액세스 메모리(RAM), 판독 전용 메모리(ROM), 하드 디스크, 또는 임의의 다른 유형의 메모리 저장 디바이스를 포함할 수 있다. 착탈식 메모리(46)는 가입자 식별 모듈(SIM) 카드, 메모리 스틱, 보안 디지털(SD) 메모리 카드 등을 포함할 수 있다. 다른 실시예들에서, 프로세서(32)는 서버 또는 홈 컴퓨터와 같은, 장치(30)상에 물리적으로 위치되지 않는 메모리로부터 정보에 액세스할 수 있고, 그 메모리에 데이터를 저장할 수 있다. 프로세서(32)는 시스템의 상태를 반영하기 위해 또는 사용자로부터 입력을 획득하기 위해 또는 능력들 또는 설정들에 관한 정보를 사용자에게 표시하기 위해 디스플레이 상의 시각적 표시들을 제어하도록 구성될 수 있다. 디스플레이 상에 보여질 수 있는 그래픽 사용자 인터페이스는 사용자가 본원에서 설명된 기능성을 상호작용적으로 행할 수 있게 하기 위해 API에 따라 계층화될 수 있다.
프로세서(32)는 전원(48)으로부터 전력을 수신할 수 있고, 장치(30) 내의 다른 구성요소들에 전력을 분배하고/거나 그러한 구성요소들에 대한 전력을 제어하도록 구성될 수 있다. 전원(48)은 장치(30)에 전력을 공급하기 위한 임의의 적합한 디바이스일 수 있다. 예컨대, 전원(48)은 하나 이상의 건전지 배터리들(예컨대, 니켈 카드뮴(NiCd), 니켈-아연(NiZn), 니켈 금속 수소화물(nickel metal hydride)(NiMH), 리튬-이온(Li-이온) 등), 태양 전지들, 연료 전지들 등을 포함할 수 있다.
프로세서(32)는 또한 장치(30)의 현재 위치에 관한 위치 정보(예컨대, 경도 및 위도)를 제공하도록 구성되는 GPS 칩셋(50)에 결합될 수 있다. 장치(30)는, 실시예와 일관성을 유지하면서, 임의의 적합한 위치 결정 방법에 의해 위치 정보를 획득할 수 있다는 것이 인식될 것이다.
프로세서(32)는 다른 주변기기들(52)에 추가로 결합될 수 있는데, 이러한 주변기기들은, 부가적인 특징들, 기능성, 및/또는 유선 또는 무선 연결성을 제공하는 하나 이상의 소프트웨어 및/또는 하드웨어 모듈을 포함할 수 있다. 예컨대, 주변기기들(52)은 가속도계, 생체인식(예컨대, 지문) 센서들, 전자나침반과 같은 다양한 센서들, 위성 송수신기, (사진들 또는 비디오를 위한) 디지털 카메라, 범용 직렬 버스(USB) 포트 또는 다른 상호연결 인터페이스들, 진동 디바이스, 텔레비전 송수신기, 핸즈프리 헤드셋, 블루투스® 모듈, 주파수 변조(FM) 라디오 유닛, 디지털 음악 플레이어, 미디어 플레이어, 비디오 게임 플레이어 모듈, 인터넷 브라우저 등을 포함할 수 있다.
장치(30)는, 다른 장치들 또는 디바이스들, 이를테면, 센서, 소비자 전자기기, 스마트 워치 또는 스마트 의류와 같은 웨어러블 디바이스, 의료 또는 전자보건 디바이스, 로봇, 산업 장비, 드론, 자동차, 트럭, 기차, 또는 비행기와 같은 차량에 구현될 수 있다. 장치(30)는 주변기기들(52) 중 하나를 포함할 수 있는, 상호연결 인터페이스와 같은 하나 이상의 상호연결 인터페이스를 통해 다른 구성요소들, 모듈들, 또는 그러한 장치들 또는 디바이스들의 시스템들에 연결될 수 있다. 대안적으로, 장치(30)는, 장치들 또는 디바이스들, 이를테면, 센서, 소비자 전자기기, 스마트 워치 또는 스마트 의류와 같은 웨어러블 디바이스, 의료 또는 전자보건 디바이스, 로봇, 산업 장비, 드론, 자동차, 트럭, 기차, 또는 비행기와 같은 차량을 포함할 수 있다.
도 30d는 M2M 서버, 게이트웨이, 디바이스, 또는 다른 노드 또는 장치와 같은 M2M 네트워크의 하나 이상의 논리 엔티티 또는 노드를 구현하는 데 또한 사용될 수 있는 예시적인 컴퓨팅 시스템(90)의 블록도이다. 컴퓨팅 시스템(90)은 컴퓨터 또는 서버를 포함할 수 있고, 주로 컴퓨터 판독가능 명령어들에 의해 제어될 수 있으며, 컴퓨터 판독가능 명령어들은 소프트웨어의 형태로 어디에든 있을 수 있거나, 어떤 수단에 의해서든 그러한 소프트웨어가 저장되거나 액세스된다. 컴퓨팅 시스템(90)은 논리 엔티티들, 이를테면, DSLT-TF(1202); DSLT-MF(1204 및 1206); DSLT-CF(1208, 1210, 1212, 및 1214); DSLT-MF API(1302)' DSLT-MF 처리(1304); DSLT-MF 시퀀스 처리(1306); DSLT-MF 정책 엔진(1308); DSLT-MF 스케줄러(1310); DSLT-CF API(1402); DSLT-CF 처리(1404); DSLT-CF 시퀀스 처리(1406); DSLT-MF CSF(2304); 서비스 계층(102); 애플리케이션 프로토콜들(104); 애플리케이션들(106); CSE(302, 306, 306 및 2302); AE(304, 704, 706, 708 및 2306), NSE(308), IoT 애플리케이션(1002 및 1230), IoT 디바이스(1004, 1006, 1008, 1234, 1236, 1238 및 1240); IoT 서버(1102 및 1232); IoT 게이트웨이(1242); IN-CSE(2702); ASN-CSE(2704 및 2706) 및 인터페이스들(2902, 2904, 2906 및 2908)과 같은 인터페이스들을 생성하기 위한 논리 엔티티들을 실행하거나 포함할 수 있다. 컴퓨팅 시스템(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) 버스이다.
시스템 버스(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)은 도 30a 및 도 30b의 네트워크(12)와 같은 외부 통신 네트워크에 컴퓨팅 시스템(90)을 연결하여, 컴퓨팅 시스템(90)이 네트워크의 다른 노드들과 통신할 수 있게 하기 위해 사용될 수 있는, 예컨대 네트워크 어댑터(97)와 같은 통신 회로를 포함할 수 있다.
사용자 장비(UE)는 통신을 위해 최종 사용자에 의해 사용되는 임의의 디바이스일 수 있다. 사용자 장비(UE)는 핸드헬드 텔레폰, 모바일 광대역 어댑터가 구비된 랩톱 컴퓨터, 또는 임의의 다른 디바이스일 수 있다. 예컨대, UE는 도 30a-b의 M2M 단말 디바이스(18) 또는 도 30c의 디바이스(30)로서 구현될 수 있다.
본원에서 설명된 임의의 또는 모든 시스템들, 방법들 및 프로세스들은, 컴퓨터 판독가능 저장 매체 상에 저장된 컴퓨터 실행 가능 명령어들(즉, 프로그램 코드)의 형태로 구현될 수 있으며, 그 명령어들은, 예컨대, M2M 서버, 게이트웨이, 디바이스 등을 포함하는 M2M 네트워크의 노드 또는 장치와 같은 머신에 의해 실행될 때, 본원에서 설명된 시스템들, 방법들 및 프로세스들을 수행 및/또는 구현한다는 것이 이해된다. 구체적으로, DSLT-TF(1202); DSLT-MF(1204 및 1206); DSLT-CF(1208, 1210, 1212, 및 1214); DSLT-MF API(1302)' DSLT-MF 처리(1304); DSLT-MF 시퀀스 처리(1306); DSLT-MF 정책 엔진(1308); DSLT-MF 스케줄러(1310); DSLT-CF API(1402); DSLT-CF 처리(1404); DSLT-CF 시퀀스 처리(1406); DSLT-MF CSF(2304); 서비스 계층(102); 애플리케이션 프로토콜들(104); 애플리케이션들(106); CSE(302, 306, 306 및 2302); AE(304, 704, 706, 708 및 2306), NSE(308), IoT 애플리케이션(1002 및 1230), IoT 디바이스(1004, 1006, 1008, 1234, 1236, 1238 및 1240); IoT 서버(1102 및 1232); IoT 게이트웨이(1242); IN-CSE(2702); ASN-CSE(2704 및 2706) 및 인터페이스들(2902, 2904, 2906 및 2908)과 같은 인터페이스들을 생성하는 디바이스들 또는 엔티티들의 동작들을 포함하는, 위에 설명된 단계들, 동작들, 또는 기능들 중 임의의 것이 컴퓨터 판독가능 저장 매체 상에 저장된 컴퓨터 실행가능 명령어들의 형태로 구현될 수 있다. 컴퓨터 판독가능 저장 매체는 임의의 비-일시적(즉, 유형의 또는 물리적) 방법, 또는 정보의 저장을 위한 기술로 구현된 휘발성 및 불휘발성, 착탈식 및 비-착탈식 매체 둘 모두를 포함하지만, 그러한 컴퓨터 판독가능 저장 매체는 신호들을 포함하지 않는다. 컴퓨터 판독가능 저장 매체는 RAM, ROM, EEPROM, 플래시 메모리 또는 다른 메모리 기술, CD-ROM, 디지털 다기능 디스크(DVD)들 또는 다른 광학 디스크 저장소, 자기 카세트들, 자기 테이프, 자기 디스크 저장소 또는 다른 자기 저장 디바이스들, 또는 원하는 정보를 저장하는 데 사용될 수 있고 컴퓨터에 의해 액세스될 수 있는 임의의 다른 유형의 또는 물리적 매체를 포함하지만 이에 제한되지 않는다.
더욱이, 도 11, 도 12, 도 15-22, 도 27, 및 도 28에 예시된 단계들을 수행하는 엔티티들은, 도 30c 또는 도 30d에 예시된 것들과 같은, 무선 및/또는 네트워크 통신들을 위해 구성된 장치 또는 컴퓨터 시스템의 메모리에 저장되어 그의 프로세서 상에서 실행되는 소프트웨어(즉, 컴퓨터 실행가능 명령어들)의 형태로 구현될 수 있는 논리 엔티티들일 수 있다는 것이 이해된다. 즉, 도 11, 도 12, 도 15-22, 도 27, 및 도 28에 예시된 방법(들)은, 도 30c 또는 도 30d에 예시된 장치 또는 컴퓨터 시스템과 같은 장치의 메모리에 저장된 소프트웨어(즉, 컴퓨터 실행가능 명령어들)의 형태로 구현될 수 있으며, 컴퓨터 실행가능 명령어들은, 장치의 프로세서에 의해 실행될 때, 도 11, 도 12, 도 15-22, 도 27 및 도 28에 예시된 단계들을 수행한다. 도 11, 도 12, 도 15-22, 도 27 및 도 28에 예시된 엔티티들 및 연관된 기능성 중 하나 이상은 하나 이상의 가상 네트워크 기능의 형태로 구현될 수 있다는 것이 또한 이해된다. 네트워크 기능들은 반드시 직접 통신하지는 않을 수 있고, 오히려, 그러한 기능들은 전달 또는 라우팅 기능을 통해 통신할 수 있다. 도 11, 도 12, 도 15-22, 도 27 및 도 28에 예시된 임의의 송신 및 수신 단계들은, 장치의 프로세서 및 장치의 프로세서가 실행하는 컴퓨터 실행가능 명령어들(예컨대, 소프트웨어)의 제어 하에서 장치 또는 엔티티의 통신 회로에 의해 수행될 수 있다는 것이 또한 이해된다.
또한, "요청을 전송", "응답을 전송", "요청을 수신", "응답을 수신" 등과 같은 문구들은, 통신 네트워크를 통해, 예컨대, 패킷 또는 다른 정의된 비트들의 시퀀스의 형태로, 통신 네트워크 상의 엔티티로/로부터 메시지를 전송 또는 수신하는 것을 포함할 수 있으며, 메시지의 콘텐츠 또는 데이터는 요청되거나 응답되는 것을 수신자에게 알린다는 것이 또한 이해된다. 따라서, 예컨대, "요청을 전송"이라는 문구는, "요청하는 메시지를 전송", "요청을 포함하는 메시지를 전송" 등의 문구들과 등가일 수 있다.
본 개시내용의 주제의 바람직한 실시예들을 설명할 시, 도면들에 예시된 바와 같은 특정 용어는 명확화를 위해 이용된다. 그러나, 청구된 주제는 그렇게 선택된 특정 용어로 제한되도록 의도되지 않으며, 각각의 특정 요소는 유사한 목적을 달성하기 위해 유사한 방식으로 동작하는 모든 기술적 등가물들을 포함한다는 것이 이해되어야 한다.
이러한 기재된 설명은, 최상의 방식을 비롯해 본 발명을 개시하기 위해 그리고 또한 관련 기술분야의 통상의 기술자로 하여금 임의의 디바이스들 또는 시스템들을 제조하여 사용하고 임의의 포함된 방법들을 수행하는 것을 비롯해 본 발명을 실시할 수 있게 하기 위해 예들을 사용한다. 본 발명의 특허가능한 범위는 청구항들에 의해 정의되며, 관련 기술분야의 통상의 기술자들에게 생각나는 다른 예들을 포함할 수 있다. 그러한 다른 예들은, 예들이 청구항들의 문언과 상이하지 않은 요소들을 갖는 경우 또는 예들이 청구항들의 문언과 비실질적인 차이들을 갖는 등가의 요소들을 포함하는 경우, 청구항들의 범위 내에 있는 것으로 의도된다.

Claims (20)

  1. 프로세서 및 메모리를 포함하는 장치로서,
    상기 장치의 메모리에 저장된 컴퓨터 실행가능 명령어들을 더 포함하며, 상기 명령어들은, 상기 장치의 프로세서에 의해 실행될 때, 상기 장치로 하여금, 통신 네트워크의 제1 서비스 계층 엔티티를 구현하여 상기 제1 서비스 계층 엔티티로 하여금,
    상기 통신 네트워크 상에서 실행되는 애플리케이션으로부터 분산형 트랜잭션에 대한 요청을 수신하게 하고 ― 상기 요청은 표적화된 리소스들의 세트 상에서 원자적으로 실행될 명령을 특정하고, 상기 표적화된 리소스들은 상기 통신 네트워크의 다수의 다른 서비스 계층 엔티티들에 의해 호스팅됨 ―;
    상기 다수의 다른 서비스 계층 엔티티들 각각에, 다른 서비스 계층 엔티티에 의해 호스팅되는 임의의 표적화된 리소스들을 잠그기 위한 요청을 전송하게 하고,
    상기 다수의 다른 서비스 계층 엔티티들 각각으로부터, 서비스 계층 엔티티가 상기 서비스 계층 엔티티에 의해 호스팅되는 표적화된 리소스들을 잠글 수 있었는지 여부를 표시하는 응답을 수신하게 하고,
    상기 다수의 다른 서비스 계층 엔티티들에, 상기 다수의 다른 서비스 계층 엔티티들이 상기 표적화된 리소스들의 세트를 잠글 수 있었다는 것을 표시하는 응답들을 수신하는 것에 기반하여, 상기 표적화된 리소스들의 세트 상에서 상기 명령의 원자적 실행을 수행하기 위한 요청들을 전송하게 하고,
    상기 다수의 다른 서비스 계층 엔티티들로부터, 상기 명령이 상기 표적화된 리소스들의 세트 상에서 성공적으로 실행되었다는 것을 표시하는 응답들을 수신하게 하고,
    상기 다수의 다른 서비스 계층 엔티티들에, 상기 명령이 상기 표적화된 리소스들의 세트 상에서 성공적으로 실행되었다는 것을 표시하는 응답들을 수신하는 것에 기반하여, 상기 분산형 트랜잭션을 커밋하기 위한 요청들을 전송하게 하고,
    상기 애플리케이션에, 상기 분산형 트랜잭션이 성공적으로 수행되었음을 표시하는 응답을 전송하게 하는, 프로세서 및 메모리를 포함하는 장치.
  2. 제1항에 있어서,
    상기 컴퓨터 실행가능 명령어들은, 상기 제1 서비스 계층 엔티티로 하여금 추가로, 상기 애플리케이션으로부터 상기 분산형 트랜잭션에 대한 요청을 수신할 시, 상기 제1 서비스 계층 엔티티의 메모리에, 상기 분산형 트랜잭션을 표현하고 상기 분산형 트랜잭션의 상태에 관한 정보를 포함하는 리소스를 생성하게 하며, 상기 리소스는 상기 통신 네트워크를 통해 상기 애플리케이션에 대해 액세스가능하게 되는, 프로세서 및 메모리를 포함하는 장치.
  3. 제2항에 있어서,
    상기 리소스는, 상기 트랜잭션을 고유하게 식별하는 트랜잭션 식별자 속성, 및 상기 분산형 트랜잭션의 상태에 관한 정보가 저장되는 트랜잭션 상태 속성을 포함하는, 프로세서 및 메모리를 포함하는 장치.
  4. 제2항에 있어서,
    상기 리소스는, 상기 제1 서비스 계층 엔티티가 상기 분산형 트랜잭션에 대한 요청의 처리를 개시할 때를 제어하는 실행 시간 속성을 포함하는, 프로세서 및 메모리를 포함하는 장치.
  5. 제1항에 있어서,
    상기 장치는 상기 통신 네트워크의 서버 또는 게이트웨이 중 하나를 포함하는, 프로세서 및 메모리를 포함하는 장치.
  6. 제1항에 있어서,
    상기 컴퓨터 실행가능 명령어들은, 상기 제1 서비스 계층 엔티티로 하여금 추가로, 상기 분산형 트랜잭션에 대한 요청을, 상기 요청을 처리하기 위한 규칙들을 정의하는 정책에 따라 처리하게 하는, 프로세서 및 메모리를 포함하는 장치.
  7. 제1항에 있어서,
    상기 컴퓨터 실행가능 명령어들은, 상기 제1 서비스 계층 엔티티로 하여금 추가로, 상기 분산형 트랜잭션에 대한 요청의 처리를 스케줄링하게 하는, 프로세서 및 메모리를 포함하는 장치.
  8. 제1항에 있어서,
    상기 분산형 트랜잭션에 대한 요청은 요청들의 시퀀스의 일부인, 프로세서 및 메모리를 포함하는 장치.
  9. 제1항에 있어서,
    상기 컴퓨터 실행가능 명령어들은, 상기 제1 서비스 계층 엔티티로 하여금 추가로, 상기 다수의 다른 서비스 계층 엔티티들에, 상기 명령의 실행에 대한 제약들을 표시하는 기준들을 전송하게 하는, 프로세서 및 메모리를 포함하는 장치.
  10. 제1항에 있어서,
    상기 컴퓨터 실행가능 명령어들은, 상기 제1 서비스 계층 엔티티로 하여금 추가로, 요청된 상기 분산형 트랜잭션에 우선순위를 배정하게 하는, 프로세서 및 메모리를 포함하는 장치.
  11. 방법으로서,
    통신 네트워크의 제1 서비스 계층 엔티티에서, 상기 통신 네트워크 상에서 실행되는 애플리케이션으로부터 분산형 트랜잭션에 대한 요청을 수신하는 단계 ― 상기 요청은 표적화된 리소스들의 세트 상에서 원자적으로 실행될 명령을 특정하고, 상기 표적화된 리소스들은 상기 통신 네트워크의 다수의 다른 서비스 계층 엔티티들에 의해 호스팅됨 ―;
    상기 제1 서비스 계층 엔티티에 의해, 상기 다수의 다른 서비스 계층 엔티티들 각각에, 다른 서비스 계층 엔티티에 의해 호스팅되는 임의의 표적화된 리소스들을 잠그기 위한 요청을 전송하는 단계;
    상기 제1 서비스 계층 엔티티에 의해, 다수의 서비스 계층 엔티티들 각각으로부터, 서비스 계층 엔티티가 상기 서비스 계층 엔티티에 의해 호스팅되는 표적화된 리소스들을 잠글 수 있었는지 여부를 표시하는 응답을 수신하는 단계;
    상기 제1 서비스 계층 엔티티에 의해, 상기 다수의 다른 서비스 계층 엔티티들에, 상기 다수의 다른 서비스 계층 엔티티들이 상기 표적화된 리소스들의 세트를 잠글 수 있었다는 것을 표시하는 응답들을 수신하는 것에 기반하여, 상기 표적화된 리소스들의 세트 상에서 상기 명령의 원자적 실행을 수행하기 위한 요청들을 전송하는 단계;
    상기 제1 서비스 계층 엔티티에 의해, 상기 다수의 다른 서비스 계층 엔티티들로부터, 상기 명령이 상기 표적화된 리소스들의 세트 상에서 성공적으로 실행되었다는 것을 표시하는 응답들을 수신하는 단계;
    상기 제1 서비스 계층 엔티티에 의해, 상기 다수의 다른 서비스 계층 엔티티들에, 상기 명령이 상기 표적화된 리소스들의 세트 상에서 성공적으로 실행되었다는 것을 표시하는 응답들을 수신하는 것에 기반하여, 상기 분산형 트랜잭션을 커밋하기 위한 요청들을 전송하는 단계; 및
    상기 애플리케이션에, 상기 분산형 트랜잭션이 성공적으로 수행되었다는 것을 표시하는 응답을 전송하는 단계를 포함하는, 방법.
  12. 제11항에 있어서,
    상기 제1 서비스 계층 엔티티에 의해, 상기 애플리케이션으로부터 상기 분산형 트랜잭션에 대한 요청을 수신할 시, 상기 분산형 트랜잭션을 표현하고 상기 분산형 트랜잭션의 상태에 관한 정보를 포함하는 리소스를 생성하는 단계를 더 포함하며, 상기 리소스는 상기 통신 네트워크를 통해 상기 애플리케이션에 대해 액세스가능하게 되는, 방법.
  13. 제12항에 있어서,
    상기 리소스는, 상기 트랜잭션을 고유하게 식별하는 트랜잭션 식별자 속성, 및 상기 분산형 트랜잭션의 상태에 관한 정보가 저장되는 트랜잭션 상태 속성을 포함하는, 방법.
  14. 제12항에 있어서,
    상기 리소스는, 상기 제1 서비스 계층 엔티티가 상기 분산형 트랜잭션에 대한 요청의 처리를 개시할 때를 제어하는 실행 시간 속성을 포함하는, 방법.
  15. 제11항에 있어서,
    상기 제1 서비스 계층 엔티티는 상기 통신 네트워크의 서버 또는 게이트웨이 중 하나 상에서 구현되는, 방법.
  16. 제11항에 있어서,
    상기 분산형 트랜잭션에 대한 요청을 상기 요청을 처리하기 위한 규칙들을 정의하는 정책에 따라 처리하는 단계를 더 포함하는, 방법.
  17. 제11항에 있어서,
    상기 분산형 트랜잭션에 대한 요청의 처리를 스케줄링하는 단계를 더 포함하는, 방법.
  18. 제11항에 있어서,
    상기 분산형 트랜잭션에 대한 요청은 요청들의 시퀀스의 일부인, 방법.
  19. 제11항에 있어서,
    상기 다수의 다른 서비스 계층 엔티티들에, 상기 명령의 실행에 대한 제약들을 표시하는 기준들을 전송하는 단계를 더 포함하는, 방법.
  20. 제11항에 있어서,
    요청된 상기 분산형 트랜잭션에 우선순위를 배정하는 단계를 더 포함하는, 방법.
KR1020197030278A 2017-03-17 2018-03-16 네트워크 서비스 계층에서의 분산형 트랜잭션 관리 KR102436426B1 (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201762472851P 2017-03-17 2017-03-17
US62/472,851 2017-03-17
PCT/US2018/022856 WO2018170391A1 (en) 2017-03-17 2018-03-16 Distributed transaction management in a network service layer

Publications (2)

Publication Number Publication Date
KR20190129934A true KR20190129934A (ko) 2019-11-20
KR102436426B1 KR102436426B1 (ko) 2022-08-26

Family

ID=61972200

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020197030278A KR102436426B1 (ko) 2017-03-17 2018-03-16 네트워크 서비스 계층에서의 분산형 트랜잭션 관리

Country Status (6)

Country Link
US (2) US10812571B2 (ko)
EP (1) EP3596909B1 (ko)
JP (1) JP7142641B2 (ko)
KR (1) KR102436426B1 (ko)
CN (1) CN110521188B (ko)
WO (1) WO2018170391A1 (ko)

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110521188B (zh) * 2017-03-17 2022-10-11 康维达无线有限责任公司 网络服务层中的分布式事务管理
US11025627B2 (en) * 2017-07-10 2021-06-01 Intel Corporation Scalable and secure resource isolation and sharing for IoT networks
TWI635413B (zh) 2017-07-18 2018-09-11 義隆電子股份有限公司 指紋感測積體電路
EP3725107A1 (en) * 2017-12-14 2020-10-21 Telefonaktiebolaget LM Ericsson (publ) Communications with constrained devices
US20210044479A1 (en) * 2018-02-07 2021-02-11 Telefonaktiebolage LM Erisson (publ) Technique for establishing a communication hierarchy among a plurality of devices
US11243978B2 (en) * 2018-06-29 2022-02-08 EMC IP Holding Company LLC Non-centralized data synchronization for IoT and other distributed applications
US11398951B2 (en) * 2019-01-21 2022-07-26 Vmware, Inc. Automatic generation of configurations for IoT endpoints
KR102167160B1 (ko) * 2019-08-08 2020-10-16 에스케이 텔레콤주식회사 서비스호스팅 환경제어 방법 및 장치
CN112134958B (zh) * 2020-09-23 2022-04-15 北京奇艺世纪科技有限公司 数据请求方法、装置、服务器及存储介质
US11681570B2 (en) * 2021-01-29 2023-06-20 Microsoft Technology Licensing, Llc Environment-based device condition indicator for prioritized device-cloud interactions
CN114422558A (zh) * 2021-12-29 2022-04-29 国网天津市电力公司 基于容器边缘代理的数据报文转换自描述协议mqtt方法
US11729081B2 (en) * 2022-01-20 2023-08-15 International Business Machines Corporation Enhancing software application hosting in a cloud environment

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5835757A (en) * 1994-03-30 1998-11-10 Siemens Telecom Networks Distributed database management system for servicing application requests in a telecommunications switching system

Family Cites Families (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5687363A (en) * 1994-03-30 1997-11-11 Siemens Stromberg-Carlson Distributed database architecture and distributed database management system for open network evolution
US7430570B1 (en) * 2003-04-28 2008-09-30 Ibrix, Inc. Shadow directory structure in a distributed segmented file system
GB0519981D0 (en) * 2005-09-30 2005-11-09 Ignios Ltd Scheduling in a multicore architecture
JPWO2007088728A1 (ja) * 2006-01-31 2009-06-25 ヒューレット−パッカード デベロップメント カンパニー エル．ピー． 多層分散処理システム
US8639267B2 (en) * 2008-03-14 2014-01-28 William J. Johnson System and method for location based exchanges of data facilitating distributed locational applications
US20100318394A1 (en) * 2009-06-15 2010-12-16 Microsoft Corporation Executing transactions as an atomic unit
JP2012018449A (ja) * 2010-07-06 2012-01-26 Fujitsu Ltd スナップショット取得処理プログラム、スナップショット取得処理方法、スナップショット・パティシパント・コンピュータ、スナップショット・コーディネータ・コンピュータ
CN102136976B (zh) * 2011-02-24 2014-12-31 华为技术有限公司 一种机器事务控制方法、装置和系统
CN103503487B (zh) * 2011-03-03 2017-05-03 交互数字专利控股公司 用于接入隶属于所发现的服务供应商的服务的方法和装置
US8463958B2 (en) * 2011-08-08 2013-06-11 Arm Limited Dynamic resource allocation for transaction requests issued by initiator devices to recipient devices
EP3025525B1 (en) * 2013-07-25 2018-12-12 Convida Wireless, LLC End-to-end m2m service layer sessions
GB2522057B (en) * 2014-01-13 2021-02-24 Advanced Risc Mach Ltd A data processing system and method for handling multiple transactions
US9519510B2 (en) * 2014-03-31 2016-12-13 Amazon Technologies, Inc. Atomic writes for multiple-extent operations
US9569459B1 (en) * 2014-03-31 2017-02-14 Amazon Technologies, Inc. Conditional writes at distributed storage services
CN111405493B (zh) * 2014-07-07 2022-08-12 康维达无线有限责任公司 用于基于机器类型通信组的服务的协调分组
US10129031B2 (en) * 2014-10-31 2018-11-13 Convida Wireless, Llc End-to-end service layer authentication
CN105653374B (zh) * 2014-11-12 2020-04-28 华为技术有限公司 分布式事务资源执行的方法、装置和系统
US9654294B2 (en) 2015-02-26 2017-05-16 Red Hat, Inc. Non-repudiable atomic commit
CN107977376B (zh) * 2016-10-24 2020-07-07 腾讯科技（深圳）有限公司 分布式数据库系统及事务处理方法
CN110521188B (zh) * 2017-03-17 2022-10-11 康维达无线有限责任公司 网络服务层中的分布式事务管理
US10691506B2 (en) * 2018-12-28 2020-06-23 Intel Corporation Distributed lock for data acquisition systems

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5835757A (en) * 1994-03-30 1998-11-10 Siemens Telecom Networks Distributed database management system for servicing application requests in a telecommunications switching system

Also Published As

Publication number Publication date
EP3596909A1 (en) 2020-01-22
WO2018170391A1 (en) 2018-09-20
US20200412796A1 (en) 2020-12-31
KR102436426B1 (ko) 2022-08-26
US11184428B2 (en) 2021-11-23
EP3596909B1 (en) 2022-10-05
JP2020514912A (ja) 2020-05-21
CN110521188B (zh) 2022-10-11
US10812571B2 (en) 2020-10-20
JP7142641B2 (ja) 2022-09-27
CN110521188A (zh) 2019-11-29
US20180270295A1 (en) 2018-09-20

Similar Documents

Publication Publication Date Title
KR102436426B1 (ko) 네트워크 서비스 계층에서의 분산형 트랜잭션 관리
KR102112106B1 (ko) 서비스 계층 동적 권한부여
KR102523861B1 (ko) 가입 및 통지 서비스
EP3195526B1 (en) Layered management server delegation
US20180270314A1 (en) Enhanced restful operations
JP2017537422A (ja) サービス層における交渉サービスをサポートする方法
KR102355746B1 (ko) 서비스 계층 등록
US11671514B2 (en) Service layer message templates in a communications network
KR20200097724A (ko) Iot/m2m 서비스 계층에서의 데이터 또는 서비스들에 대한 컨텍스트 인식 허가를 가능하게 하는 방법들
US11985195B2 (en) Methods to enable data continuity service
US11134365B2 (en) Resource link management at service layer
WO2019067817A1 (en) ENHANCED RESOURCE SHARING USING A RESERVATION
CN113302899A (zh) 通信网络中的自动服务层消息流管理
CN111989941A (zh) 用于分流IoT应用消息生成和响应处理的服务层方法

Legal Events

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