KR102092743B1 - 사물 인터넷 단-대-단 서비스 계층의 서비스 품질 관리 - Google Patents

Abstract

방법들, 시스템, 및 장치들은 서비스 계층(SL) 세션들의 사용을 통해 단-대-단(E2E) 서비스 품질(QoS)을 지원할 수 있다. 예를 들어, 애플리케이션은 애플리케이션 특정된 스케줄, 레이턴시, 지터, 에러율, 처리율, 보안의 레벨, 비용 요건들에 기초하여 타깃된 디바이스와 통신할 수 있다. 예시적인 시스템(150)은 단-대-단 방식으로 QoS를 관리하는 메커니즘들을 지원한다. 시스템(150)은 애플리케이션(156)이 온-디맨드 E2E QoS 요건들을 특정하기를 요구하는 사용 경우들을 지원한다. 온-디맨드 E2E QoS 요건들은 무엇보다도, 통신의 도달가능성 스케줄(예를 들어, 애플리케이션이 타깃된 M2M/IoT 디바이스가 그것의 SL 요구들을 서비스하도록 도달가능하게 되기를 요구할 때), E2E 레이턴시, E2E 처리율, E2E 지터, E2E 에러율, E2E 보안 레벨, 또는 E2E 비용을 포함할 수 있다. 시스템(150)은 근거리 지역과 원거리 지역 기반 네트워크들(예를 들어, 3GPP(161), 브로드밴드 이더넷(162), 와이파이(163), 또는 6LoWPAN(164))의 다양한 조합을 통해 서로 상호접속된 IoT 서버들(예를 들어, IoT 서버(152)), IoT 게이트웨이들(예를 들어, IoT 게이트웨이(151)), 및 디바이스들(예를 들어, IoT 필드 디바이스(153) 또는 IoT 디바이스(154))를 포함한다. 서버들 및 게이트웨이들 상에 호스트된 것은 IoT SL들(예를 들어, IoT SL(166) 또는 IoT SL(165))의 인스턴스들이다. 백엔드 내의 디바이스들뿐만 아니라 필드 내의 디바이스들 상에 호스트된 것은 서로 통신하는 IoT 애플리케이션들(예를 들어, IoT 디바이스 애플리케이션(155) 및 IoT 애플리케이션(156))이다. 예를 들어, 환자의 IoT 센서 또는 액추에이터와 백엔드 환자 감시 애플리케이션 간의 E2E 통신. 시스템(150)은 서비스 계층 접속 관리자(SLCM) 기능(예를 들어, SLCM(157) 또는 SLCM(158)), 애플리케이션 접속 관리자(ACM) 기능(예를 들어, ACM(159) 또는 ACM(160)) 및 기반 네트워크 접속 관리자(UNCM) 기능(예를 들어, UNCM(167), UNCM(168), 또는 UNCM(169))을 포함한다. SLCM과 함께, ACM, 및 UNCM 기능들은 E2E QoS의 지원으로 IoT 디바이스들, 게이트웨이들, 서버들, 및 애플리케이션들의 단-대-단 기반 네트워크 QoS 및 접속을 보다 지능적으로 관리하고 구성하기 위해 서로 상호작용한다.

Description

사물 인터넷 단-대-단 서비스 계층의 서비스 품질 관리

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

본원은 그 내용들이 본원에 참조로 포함된 "Internet of Things End-to-End Service Layer Quality of Service Management"라고 하는 2015년 8월 4일자 출원된 미국 가 특허 출원 번호 제62/200,752호를 우선권 주장한다.

M2M/IoT SL

M2M/IoT 서비스 계층(SL)은 M2M/IoT 디바이스들 및 응용들을 위한 부가 가치 서비스들을 제공하는 것을 특별히 목표로 하는 기술이다. 최근, 여러가지 산업 표준 단체들(예를 들어, oneM2M 기능 아키텍처-V-1.6.1 및 ETSI TS 102 690 머신 대 머신 통신(M2M) 기능 아키텍처 V2.0.13)이 M2M/IoT 디바이스들 및 응용들을 인터넷/웹, 셀룰러, 기업, 및 홈 네트워크를 갖는 구축들로 통합하는 것과 연관된 도전들을 해결하기 위해 M2M/IoT SL들을 개발하여 왔다.

머신 대 머신/사물 인터넷(M2M/IoT) 서비스 계층(SL)은 M2M/IoT 지향된 능력들의 수집에의 액세스를 제공할 수 있다. 몇가지 예시적인 능력들은 보안, 과금, 데이터 관리, 디바이스 관리, 발견, 제공, 및 접속 관리를 포함한다. 그 전체가 참조로 포함된 oneM2M-TS-0001, oneM2M 기능 아키텍처-V-1.6.1을 참조할 수 있다. 능력들이 M2M/IoT SL에 의해 지원된 메시지 형식들, 리소스 구조들, 및 리소스 표현들을 사용하는 애플리케이션 프로그래밍 인터페이스들(API들)을 통해 응용들에 가용하게 될 수 있다.

도 1은 서비스 계층을 지원할 수 있는 예시적인 프로토콜 스택을 도시한다. 프로토콜 스택 관점으로부터, SL(101)은 애플리케이션 프로토콜 계층(102) 위에 그리고 애플리케이션 계층(103) 아래에 놓일 수 있고 지원된 애플리케이션들에 부가 가치 서비스들을 제공할 수 있다. SL(101)은 '미들웨어' 서비스들로서 분류될 수 있다.

세션들

통신 세션은 전형적으로 2개 이상의 통신 엔티티들(예를 들어, 디바이스들, 애플리케이션들 등) 간의 정보의 지속적인 상호작용 교환을 포함한다. 통신 세션은 소정의 시점에서 확립되고, 다양한 상황들에 기초하여 (예를 들어, 세션 시간이 종료한 후에 또는 엔티티들 중 하나가 세션을 종료하기를 결정할 때) 나중 시점에 해체된다. 통신 세션은 엔티티들 간의 다중 메시지들의 교환을 포함할 수 있고 네트워크 접속 상태를 추적할 수 있다. 네트워크 접속 상태를 추적할 수 있다는 것은 통신 엔티티들 중 적어도 하나가 통신 세션(예를 들어, 접속, 등록, 보안, 스케줄링, 및 세션 참여자들에 적용가능한 데이터)를 유지할 수 있기 위해서 세션 이력에 관한 정보를 저장하는 것을 의미할 수 있다. 통신 세션들은 네트워크 프로토콜 스택 내의 다양한 계층들에서의 프로토콜들 및 서비스들의 일부로서 구현될 수 있다. 한 예로서, 도 2는 네트워크 노드(104)와 네트워크 노드(105) 사이에 확립된 통신 세션들을 도시한다. 위에 언급된 네트워크 노드들(104 및 105)의 통신 세션들은 트랜스포트 프로토콜 계층(110)(예를 들어, TCP 접속), 세션 프로토콜 계층(109)(예를 들어, TLS 및 DTLS 세션들), 웹 트랜스포트 프로토콜 계층(108)(예를 들어, HTTP 및 CoAP 세션들), M2M/IoT SL(107)(예를 들어, oneM2M 세션들), 및 애플리케이션-특정 세션들(106)에 기초할 수 있다.

통상적인 애플리케이션 세션은 기반 통신 프로토콜 및 서비스 계층에 의해서 보다는 애플리케이션들 자체에 의해 확립되고 관리되는 2개 이상의 애플리케이션들 사이의 통신 세션이다. 결과적으로, 애플리케이션 세션들은 애플리케이션들에 추가 오버헤드 및 복잡성을 부가할 수 있다. 예를 들어, 통상적인 애플리케이션 세션은 애플리케이션들이 세션 자체들을 구성, 확립, 및 관리하기를 요구할 수 있다. 이것은 크리덴셜들, 식별자들, 라우팅 정보, 발견 정보, 위치, 트랜잭션 이력, 및 데이터와 같은 세션 콘텍스트의 생성 및 관리를 포함할 수 있다.

M2M/IoT SL 세션은 SL에 의해 지원된 부가 가치 세션 관리 서비스들에 의해 가능하게 되는 통신 세션이다. 이들 서비스는 SL 세션 및 그것의 종단점들과 관련한 콘텍스트를 수집 및 관리하는 것뿐만 아니라 SL 종단점들 간에 SL 세션을 확립하기 위한 메커니즘들과 같은 능력들을 포함할 수 있다. SL 세션은 이들 종단점이 애플리케이션들 또는 SL 인스턴스들일 수 있는 2개 이상의 SL 세션 종단점들 사이에 확립될 수 있다. 그러나 최소한으로, SL의 적어도 하나의 인스턴스는 SL 세션의 촉진제로서 기능하기 위해 세션에 참여하여야 한다(예를 들어, 필요한 SL 세션 관리 기능성을 제공하여야 한다). 'SL 인스턴스'는 서비스 계층(예를 들어, 디바이스 상에 호스트된 서비스)의 단일 인스턴스화로서 고려될 수 있다. 'SL 세션'은 SL과 애플리케이션 사이의 통신 세션이다. SL은 다중의 동시 SL 세션들을 지원할 수 있다.

도 3은 M2M/IoT SL 세션들의 예들을 도시한다. 제1 예에서, 112에서, SL 세션이 단일 애플리케이션과 SL 인스턴스 사이에 확립된다. 이것은 그것이 SL 인스턴스를 가로질러 걸치지 않기 때문에 0-홉 SL 세션의 예이다. 제2 예는, 113에서, 2개의 SL 인스턴스들 사이에 확립된 SL 세션을 나타낸다. 이것은 0-홉 SL 세션의 또 하나의 예이다. 제3 예는, 114에서, 공통 SL 인스턴스(117)를 가로질러 걸치는 2개의 애플리케이션들 사이에 확립된 SL 세션을 나타내므로, 이것은 1-홉 SL 세션의 예이다. 제4 예는, 115에서, 2개의 SL 인스턴스들(SL 인스턴스(116) 및 SL 인스턴스(117))을 가로질러 걸치는 3개의 애플리케이션들 사이에 확립된 M2M SL 세션을 나타내고, 2-홉 SL 세션의 예이다.

M2M/IoT SL 세션들의 하나의 이점은 그들이 그들 자신의 애플리케이션-기반 세션들을 확립하고 유지하여야 한다는 부담을 애플리케이션들에서 없애게 하는데 사용될 수 있다는 것이다. 왜냐하면 SL 세션은 세션을 확립하고 유지하는 것과 관련된 오버헤드의 부담이 SL로 떠넘겨져서 애플리케이션들이 이 책임으로 부담되지 않기 때문이다. SL로 떠넘겨질 수 있는 오버헤드의 일부 예들은 크리덴셜들, 식별자들, 라우팅 정보, 발견 정보, 위치, 트랜잭션 이력, 및 데이터와 같은 세션 콘텍스트의 생성 및 관리를 포함할 수 있다.

SL 세션은 하나 이상의 기반 트랜스포트 또는 액세스 네트워크 통신 세션들의 상부 상에 층이 질 수 있다(여기서, 또한 접속들이라고 할 수 있다). 일부 예들은 웹 트랜스포트 프로토콜 세션들(예를 들어, HTTP 세션), 세션 계층 세션들(예를 들어, 트랜스포트 계층 세션(TLS)), 트랜스포트 계층 접속들(예를 들어, 전송 제어 프로토콜(TCP)), 기반 액세스 네트워크 접속들(예를 들어, 3GPP, 브로드밴드 이더넷, 와이파이, 블루투스)을 포함할 수 있다. 이 층이 진 것은 SL 세션이 SL 세션이 지속하고 하부 계층 세션들의 셋업 및 해체와 독립적으로 유지될 수 있도록 하부 계층 세션들과 관련하여 지속성을 지원하게 한다. 예를 들어, SL 세션은 (예를 들어, 절전 방법들 및 이동성으로 인해) 정상적인 네트워크 통신의 과정 중에 꽤 전형적인 반복적으로 셋업 및 해체되는 그것의 기반 TCP 또는 TLS 세션들에도 불구하고 지속할 수 있다.

세션 참여자들 간의 M2M/IoT SL 세션의 확립은 SL 등록 과정의 일부로서 또는 그 이후의 별개의 과정으로서 시작될 수 있다. 확립되고 나서, SL 세션은 세션 참여자들과 관련한 SL 콘텍스트 및 그들 사이에 일어나는 통신을 수집하고 유지하기 위해 사용될 수 있다. 예를 들어, 세션 참여자들의 등록 상태 및 보안 크리덴셜들, 세션 참여자들에 대한 가입 기준 및 연락 정보, SL 리소스들 내에 저장된 세션 참여자 데이터, 세션 참여자들에 의해 수행된 트랜잭션들의 이력과 같은 SL 세션 콘텍스트가 각각의 세션에 대해 수집되고 유지될 수 있다. 세션 참여자들 간의 SL 세션의 종료는 SL 등록 취소 과정의 일부로서 또는 등록 취소가 일어나지 전에 수행된 별도의 과정으로서 시작될 수 있다.

강조할 주목할만한 점은 특정한 SL 세션의 수명 동안의 SL 세션 콘텍스트의 누적뿐만 아니라 SL 세션의 확립은 세션 참여자들을 대신한 상당한 양의 시간과 노력과 관련할 수 있다는 것이다. 그러므로 SL 세션의 지속성은 이 지속성이 결여된 하부 계층 트랜스포트 및 액세스 네트워크 세션들과 비교하여 그것의 주된 부가 가치 차이점들 중 하나이다. 지속적인 SL 세션은 그들이 이 정보 자체를 유지하지 않아도 되도록 애플리케이션을 대신하여 SL 세션 콘텍스트를 유지하기 위해 사용될 수 있다. 또한 하부 계층 세션이 해체될 때 SL 세션 콘텍스트는 지속할 수 있고 하부 계층 접속이 재확립될 때, 이 콘텍스트는 여전이 애플리케이션에 가용할 것이다. 그러므로 이 콘텍스트는 비지속 기반 트랜스포트 세션들 또는 액세스 네트워크 접속들에 독립하여 유지될 수 있다. SL 세션 콘텍스트의 일부 예들을 애플리케이션들에 대한 SL 등록들, 가입들, 크리덴셜들, 식별자들, 과금 기록들, 라우팅 정보, 발견 정보, 위치, 트랜잭션 이력, 및 데이터를 포함할 수 있다.

oneM2M SL 아키텍처

개발 중인 oneM2M 표준(oneM2M 기능 아키텍처)은 도 4에 도시된 바와 같이, 공통 서비스 엔티티(CSE)라고 하는 서비스 계층을 정의한다. Mca 기준 점은 애플리케이션 엔티티(AE)와 인터페이스한다. Mcc 기준 점은 동일한 서비스 제공자 도메인 내에서 또 하나의 CSE와 인터페이스하고 Mcc'의 기준 점은 상이한 서비스 제공자 도메인에서 또 하나의 CSE와 인터페이스한다. Mcn 기준 점은 기반 네트워크 서비스 엔티티(NSE)와 인터페이스한다. NSE는 기반 네트워크 서비스들을 디바이스 관리, 위치 서비스들 및 디바이스 트리거링과 같은 CSE들에 제공한다. CSE는 "발견" 또는 "데이터 관리 & 리포지토리"와 같은 "공통 서비스 기능들(CSF들)"이라고 하는 다수의 논리적 기능들을 포함한다. 도 5는 oneM2M에 대한 예시적인 CSF들을 도시한다.

oneM2M 아키텍처는 애플리케이션 서비스 노드(ASN), 애플리케이션 전용 노드(ADN), 중간 노드(MN), 및 인프라스트럭처 노드(IN)를 가능하게 한다. ASN은 하나의 CSE를 포함하고 적어도 하나의 AE를 포함하는 노드이다. 물리적 맵핑의 예는 M2M 디바이스 내에 상주하는 ASN이다. ADN은 적어도 하나의 AE를 포함하고 CSE를 포함하지 않는 노드이다. 물리적 맵핑의 예는 제한된 M2M 디바이스 내에 상주하는 ADN이다. MN은 하나의 CSE를 포함하고 0개 이상의 AE를 포함하는 노드이다. MN에 대한 물리적 맵핑의 예는 M2M 게이트웨이 내에 상주하는 MN이다. IN은 하나의 CSE를 포함하고 0개 이상의 AE를 포함하는 노드이다. IN에 대한 물리적 맵핑의 예는 M2M 서비스 인프라스트럭처 내에 상주하는 IN이다. oneM2M 엔티티들(AE들도 CSE들도)을 포함하지 않는 노드인 비-oneM2M 노드가 또한 있을 수 있다. 이러한 노드들은 관리를 포함하는, 인트워킹 목적들을 위해 oneM2M 시스템에 부착된 디바이스들을 나타낸다. oneM2M 시스템 내에서 지원된 다양한 엔티티들을 상호 접속하는 가능한 구성들이 도 6에 도시된다.

TS-0001, oneM2M 기능 아키텍처, 버전 1.1.0, 2014년 8월에서의 oneM2M은 도 5에 도시한 바와 같이, 서비스 계층 세션 관리 서비스(예를 들어, SSM CSF(119))를 정의하였다. oneM2M은 SSM CSF에 의해 관리되는 단-대-단 SL 접속으로서 SL 세션을 또한 정의하였다. oneM2M은 또한 SSM CSF의 일부 요건들을 정의하였지만 그것은 이들 요건을 충족하는 아키텍처나 설계를 아직 정의하지 않았다. 예를 들어, oneM2M은 세션 관리 서비스가 다음의 특징들을 지원하는 것을 서술한다:

1) SSM CSF는 AE들 사이에, AE와 CSE 사이에, 또는 CSE들 사이에 SL 세션을 확립하라는 요구들을 지원할 것이다.

2) SSM CSF는 다수의 전이 CSE 홉들을 걸치는 SL 세션들을 지원할 것이다.

3) SL 세션을 확립하라는 요구가 허가되기 전에, SSM CSF는 미리 확립된 크리덴셜들을 사용하여 요구자를 먼저 인증할 것이다.

4) SSM CSF는 단-대-단 인증을 지원하기 위해 SEC CSF를 사용할 것이다. 인증될 때, SSM CSF는 요구하는 세션 종단점과 타깃된 세션 종단점 사이에 M2M SL을 확립할 것이다.

5) SSM CSF는 요구자에 세션 ID를 반환할 것이다.

6) SSM CSF는 또한 세션 정책들, 세션 라우팅 정보, 세션 설명자 등과 같은 세션의 관리를 위한 추가의 세션 정보를 유지할 것이다.

7) SSM CSF는 AE들 사이에, AE와 CSE 사이에, 또는 CSE들 사이의 SL 세션을 종료하라는 요구들을 지원할 것이다.

8) SSM CSF는 기반 네트워크(UN)의 상부 위에 SL 세션의 층을 만드는 것을 지원할 것이고 SSM CSF는 기반 네트워크 접속들에 대해 SL 세션들의 지속성을 지원할 것이다.

9) SSM CSF는 기반 네트워크 접속들의 상태에 독립하는 활성 SL 세션을 유지할 것이고 동적으로 해체되고 재확립되는 네트워크 접속들에 강건할 것이다.

10) SSM CSF는 네트워크 접속들이 SL 세션 활동 또는 상태에 기초하여 해체/재확립되어야 하는지에 대해 다른 CSF들 및/또는 기반 네트워크에의 입력을 시작 또는 제공하는 것을 지원할 것이다.

oneM2M은 위에 정의된 요건들을 지원하기 위해 SSM CSF의 기능성을 미리 정하여야 한다. 일반적으로, oneM2M에의 기여들로서 제출된 제안된 구현들은 상기 요건들 1 내지 7을 지원하기 위해 SSM 리소스 정의들 및 절차들을 정의하는 것에 집중한다. 도 7은 oneM2M SL 세션 관리를 위한 예시적인 리소스 구조를 도시한다. <session> 리소스는 개개의 SL 세션을 관리하기 위한 속성들 및 서브-리소스들을 포함한다.

oneM2M은 CSEBase, remoteCSE, 가입, 또는 cmdhNwAccessRules를 포함하는 페어런트 리소스 유형들의 제한된 세트를 위한 스케줄링 정보를 저장하는 데 사용될 수 있는 schedule 차일드 리소스 유형을 정의한다. 결과적으로, oneM2M 은 다음 유형들의 스케줄링을 지원한다:

1) CSE는 그것의 CSEBase 또는 remoteCSE 페어런트 리소스 하에서 schedule 차일드 리소스를 지원함으로써 그것의 도달가능성 스케줄을 정의할 수 있다. 그렇게 하는 데 있어서, CSE는 SL 요구들을 송신 또는 수신하는 것이 가용한 시간들을 선언할 수 있다.

2) CSE 리소스의 가입자(예를 들어, 애플리케이션)는 CSE가 그것에 통지들을 송신하는 시간들을 제어하는 통지 스케줄을 정의할 수 있다. 가입자는 subscription 리소스 하에서 schedule 차일드 리소스를 생성함으로써 이것을 할 수 있다.

3) CSE는 CSE가 특정한 기반 액세스 네트워크에 액세스할 수 있을 때를 정의하는 액세스 네트워크 스케줄을 지원할 수 있다. 이것은 <cmdhNwAccessRules> 리소스 하에서 <schedule> 차일드 리소스를 생성함으로써 행해질 수 있다.

oneM2M schedule 리소스는 scheduleEntry 속성을 지원한다. 이 속성은 표 1에 나타낸 바와 같이 6개의 콤마 분리된 필드들로 이루어진 스트링을 사용하는 형식으로 되는 스케줄을 정의한다. 각각의 필드는 (그것이 어떤 값과 일치한다는 것을 표시하는) 별표 '*', (그것이 특정한 값과 일치한다는 것을 표시하는) 수, 또는 (그것이 값들의 범위와 일치한다는 것을 표시하는) 하이펀 '-' 으로 분리된 2개의 수들일 수 있다.

예를 들어, ' 0-30, 30, 12, 1, * , * ' 의 스트링 값을 갖는 scheduleEntry는 초들이 '0-30'의 값, 분들 '30', 시간 '12', 월 중의 일 '1', 연 중의 월 '*', 및 주 중의 일 '*'을 갖는 스케줄로 변환한다. 예를 들어, 이 scheduleEntry가 가입 스케줄을 위해 사용되었다면, 이것은 CSE만이 매달 1일 12:30에서 시작하여 30초의 윈도우 동안 가입자에게 대응하는 통지들을 송신하게 되는 결과가 되었을 것이다. 모든 다른 시간들 동안, CSE는 다음 가입 스케줄 윈도우가 시작하는 것을 대기하는 통지들을 버퍼할 것이다.

3GPP 서비스 능력 노출 기능(SCEF)

도 8은 예시적인 3GPP 서비스 능력 노출 기능(SCEF)-기반 시스템 아키텍처를 도시한다. 3GPP는 기반 3GPP 네트워크 능력들을 애플리케이션/서비스 제공자들에게 더 잘 노출시키기 위한 프레임워크를 최근에 정의하였다. 여기에 포함된, 3GPP TS 23.682, 패킷 데이터 네트워크들 및 애플리케이션들과의 통신을 가능하게 하는 아키텍처 향상들, V13.0.0을 참조할 수 있다. 이것을 달성하기 위해서, 3GPP는 SCEF를 정의하였다. SCEF 기능은 3GPP 네트워크들에 의해 제공된 서비스들 및 능력들을 안전하게 노출하는 수단을 제공한다. SCEF는 노출된 서비스 능력들의 발견을 위한 수단을 제공한다. SCEF는 OMA, GSMA, 및 가능하게는 다른 표준화 단체들에 의해 정의된 동종 네트워크 애플리케이션 프로그래밍 인터페이스들(예를 들어, 네트워크 API)을 통해 네트워크 능력들에의 액세스를 제공한다. SCEF는 기반 3GPP 네트워크 인터페이스들 및 프로토콜들로부터 서비스들을 추출한다.

애플리케이션들이 타깃된 M2M/IoT 디바이스을 그들의 E2E QoS 요건들을 충족하는 방식으로 단-대-단 통신을 수행하게 하는 방법들, 시스템들, 및 장치들이 여기에 개시된다. 예를 들어, 애플리케이션은 애플리케이션 특정된 스케줄, 레이턴시, 지터, 에러율, 처리율, 보안의 레벨, 및 비용 요건들에 기초하여 타깃된 디바이스와 통신할 수 있다.

구체적으로, 본 개시내용은 아래를 정의한다. 첫째, 애플리케이션이 애플리케이션 특정된 QoS 선호들을 갖고 하나 이상의 SL 어드레스가능한 타깃들(예를 들어, M2M/IoT 애플리케이션, 디바이스, 또는 게이트웨이 SL 어드레스가능한 리소스)를 타깃하는 M2M/IoT SL 통신 세션을 확립, 사용, 및 해체하게 하는 방법들/절차들을 지원하는 M2M/IoT E2E SL QoS 관리를 위한 시스템.

둘째, M2M/IoT SL이 애플리케이션 특정된 E2E QoS 선호들에 기초하여 기반 네트워크 QoS 레벨을 구성, 선택, 및/또는 그에 영향을 주도록 기반 네트워크들과 상호작용하게 하는 E2E SL 세션 기반 방법들/절차들. (2개의 서비스 계층 노드들을 서로 상호접속하는) 기반 트랜스포트 네트워크는 애플리케이션에 의해 특정된 서비스 품질 요건들을 갖는 서비스 계층에 의해 구성될 수 있다.

셋째, SL들이 상이한 E2E SL 세션들에 대해 어떤 UN들을 사용할지에 대한 알려진 결정들을 할 수 있도록 UN이 UN QoS 및 M2M/IoT SL들과의 접속 관련 정보를 공유하게 하는 방법들/절차들.

넷째, M2M/IoT SL 인스턴스들이 다수의 기반 네트워크 기술들 및/또는 운영자들을 가로질러 걸치는 멀티-홉 통신 경로를 위한 E2E QoS를 조정하게 하는 E2E SL 세션 기반 방법들/절차들. 이들 방법이 다수의 SL 인스턴스들 및 애플리케이션들의 E2E 도달가능성 스케줄들을 조정하는 것을 포함하는 경우에, 다수의 기반 네트워크 홉들을 가로지르는 레이턴시 및 지터의 예산 잡기, 및 최소 처리율의 보장, 타깃된 비용 및 요구된 보안 레벨들이 또한 달성된다.

다섯째, 서로 통신할 필요가 있는 SL 엔티티들 간의 접속 스케줄, 처리율, 레이턴시, 지터, 비용, 보안 레벨들 및 에러율들과 같은 UN QoS 파라미터들의 E2E 정렬을 가능하게 하기 위해 SL 인스턴스들, 애플리케이션들 및 UN들 간에 교환될 수 있는 E2E SL 세션 QoS 정보의 정의.

여섯째, 제안된 M2M/IoT E2E SL QoS 관리 시스템의 시스템 레벨 oneM2M 및 3GPP 예.

일곱째, 제안된 SLCM, ACM, 및 UNCM 기능들의 API 레벨 예들.

첨부 도면과 함께 예로서 주어진 다음의 설명으로부터 보다 상세한 이해가 될 수 있다.
도 1은 서비스 계층을 지원하는 예시적인 프로토콜 스택을 도시하고;
도 2는 예시적인 통신 세션들을 도시하고;
도 3은 예시적인 IoT SL 세션을 도시하고;
도 4는 예시적인 oneM2M 아키텍처를 도시하고;
도 5는 예시적인 oneM2M 공통 서비스 기능들을 도시하고;
도 6은 oneM2M 아키텍처에 의해 지원된 예시적인 구성들을 도시하고;
도 7은 oneM2M SL 세션 관리를 위한 예시적인 리소스 구조를 도시하고;
도 8은 예시적인 3GPP SCEF-기반 시스템 아키텍처를 도시하고;
도 9는 예시적인 단-대-단 IoT 디바이스 통신 사용 경우를 도시하고;
도 10은 상이한 액세스 네트워크들을 포함하는 예시적인 단-대-단 통신을 도시하고;
도 11은 E2E 통신을 위한 QoS를 관리하는 예시적인 IoT 시스템을 도시하고;
도 12는 예시적인 IoT E2E QoS 관리 절차를 도시하고;
도 13은 예시적인 E2E SL 세션 QoS를 도시하고;
도 14는 E2E SL 세션 확립 동안에 UN QoS를 관리하는 예시적인 방법을 도시하고;
도 15는 E2E SL 세션 메시지들을 송신하는 동안에 UN 접속들을 관리하는 예시적인 방법을 도시하고;
도 16은 E2E SL 세션 메시지들을 수신하는 동안에 UN QoS를 관리하는 예시적인 방법을 도시하고;
도 17은 E2E SL 세션 해체를 관리하는 예시적인 방법을 도시하고;
도 18은 예시적인 oneM2M/3GPP E2E SL QoS 관리 시스템을 도시하고;
도 19는 예시적인 E2E SL 세션 QoS 요건들 <session> 속성들을 도시하고;
도 20은 예시적인 E2E SL 세션 QoS 요건들 <sessionPolicy> 속성들을 도시하고;
도 21은 예시적인 <UN> 리소스 및 속성들을 도시하고;
도 22는 예시적인 E2E SL 세션 QoS 요건들 <pointOfAccess> 속성들을 도시하고;
도 23은 <AE> 리소스를 위한 예시적인 <pointOfAccess> 차일드 리소스들을 도시하고;
도 24는 <AE> 리소스를 위한 예시적인 <pointOfAccess> 차일드 리소스들을 도시하고;
도 25는 예시적인 <UNCM> 리소스 및 속성들을 도시하고;
도 26은 예시적인 <UNCMSession> 리소스를 도시하고;
도 27은 예시적인 IoT 서비스 계층 오픈플로우를 도시하고;
도 28은 예시적인 E2E QoS 그래픽 사용자 인터페이스를 도시하고;
도 29는 SL QoS 연관된 소자들을 사용하여 발생된 예시적인 디스플레이를 도시하고;
도 30a는 IoT E2E 서비스 계층 QoS 관리체가 구현될 수 있는 예시적인 머신 대 머신(M2M) 또는 사물 인터넷(IoT) 통신 시스템의 시스템도이고;
도 30b는 도 30a에 도시된 M2M/IoT 통신 시스템 내에서 사용될 수 있는 예시적인 아키텍처의 시스템도이고;
도 30c는 도 30a에 도시된 통신 시스템 내에서 사용될 수 있는 예시적인 M2M/IoT 단말 또는 게이트웨이 디바이스의 시스템도이고;
도 30d는 도 30a의 통신 시스템의 양태들이 실시될 수 있는 예시적인 컴퓨팅 시스템의 블록도이다.

서비스 계층(SL) 세션들의 사용을 통한 단-대-단(E2E) 서비스 품질(QoS)을 지원하는 방법들, 시스템, 및 장치들이 여기에 개시된다.

도 9는 애플리케이션이 광역 네트워크에 걸치는 특정한 M2M/IoT 디바이스 애플리케이션과의 E2E 통신을 요구할 수 있는 사용 경우를 도시한다. 제1 기반 네트워크(122) 및 제2 기반 네트워크(124)를 통해 환자 감시 애플리케이션(124)에 통신 가능하게 접속된 센서들(121)이 있을 수 있다. 애플리케이션의 유형 및 디바이스의 유형의 따라, 이 통신은 특정한 E2E QoS 요건을 가질 수 있다. 예들이 아래에 제공된다. 제1 예시적인 시나리오에서, 의사는 그의 환자들 중 한 명을 원격으로 감시하기 위해 가정 내 환자 감시 서비스와 계약한다. 이 서비스는 환자의 신체 상에 놓인 센서들(121)(예를 들어, 웨어러블 의료 센서들)과 단-대-단 통신 세션을 확립하는 환자 감시 애플리케이션(125)을 사용한다. 이 환자의 상태를 적절히 감시하기 위해, 의사는 환자가 그의 약(예를 들어, 인슐린)을 취하여야 하는지 및 원하는 효과를 갖는지를 적절히 평가하기 위해 매 시간마다 센서들(121)로부터 측정값들(예를 들어, 환자의 혈당 레벨)을 서비스가 획득하기를 요구한다. 비정상적인 측정값들이 검출되면 서비스는 그에 따라 의사 또는 가족 구성원들에게 적절히 알릴 수 있다.

도 9를 계속 참조하면, 제1 예시적인 시나리오와 유사하게, 제2 예시적인 시나리오에서, 가정 내 환자 감시 서비스가 제2 환자를 원격으로 감시하기 위해 사용될 수 있다. 이 제2 환자의 상태를 적절히 감시하기 위해, 의사는 임계 이벤트가 검출될 때(예를 들어, 환자의 pulseOx가 심각한 임계에 도달할 때) 서비스가 환자의 센서들(121)로부터 발생될 수 있는 경보들에 대해 감시하기를 요구할 수 있다. 이 특정한 환자에 대해, 의사는 서비스가 그 다음에 적절한 조치들을 취할 수 있도록 서비스가 어떤 경보에 대해 센서(121)로부터 감시 애플리케이션(125)까지의 단-대-단 레이턴시가 5초 미만의 지연을 갖는 것을 보장하기를 요구한다. 적절한 조치들은 의사에게 알리는 것 또는 긴급 의료 서비스들을 포함할 수 있다.

도 9를 계속 참조하면, 제1 예시적인 시나리오와 유사하게, 제3 예시적인 시나리오에서, 동일한 가정 내 환자 감시 서비스가 제3 환자를 원격으로 감시하기 위해 의사에 의해 사용될 수 있다. 이 특정한 환자의 상태를 적절히 감시하기 위해, 의사는 서비스가 환자의 신체적 활동을 검출 및 추적하기 위해 비디오 감시를 통해 환자를 감시하기를 요구한다. 제3 환자에 대해, 의사는 감시가 5Mbps의 최소 지속되는 단-대-단 처리율을 요구하는 라이브 비디오 피드로 행해지는 것을 서비스가 보장하기를 요구할 수 있다.

백엔드 애플리케이션들일 수 있는 애플리케이션들 사이의 통신들을 지향하고, 필드에 디바이스들(예를 들어, 센서(121))을 배치한 M2M/IoT(서로 교환하여 여기서 M2M 또는 IoT라고 함) 구축들이 최상의 구현이 아닐 수 있다. 센서들(121)은 제한된 리소스일 수 있고 그들 자신의 광역 네트워크 접속을 효과적으로 지원할 수 없을 수 있다. 센서들(121)은 리소스 제한들(예를 들어, 배터리)에 이르게 할 수 있는 지속적인 관리 및 활성 네트워크 접속들을 지원하지 못할 수 있다. 이들 이유로, 많은 M2M/IoT 디바이스들은 디바이스가 네트워크와의 접속을 상실하는 기간들 동안 데이터가 액세스될 수 있도록 디바이스들에 광역 네트워크 접속 및 데이터 저장 서비스들을 제공하는 것과 같은, 부가 가치 서비스들을 위해 M2M/IoT 게이트웨이들 및 서버들에 의존할 수 있다. 결과적으로, 이 E2E 통신은 상이한 네트워크 제공자들(예를 들어, Sprint, Verizon 등)에 의해 또한 소유될 수 있는 다수의 기반 액세스 네트워크 기술들(예를 들어, 3GPP, 브로드밴드 이더넷, 와이파이 등)을 거칠 수 있다. 서비스 계층(SL) 세션들의 사용을 통한 단-대-단(E2E) 서비스 품질(QoS)을 지원하는 방법들, 시스템, 및 장치들이 여기에 개시된다. oneM2M 규격들의 제1 릴리스에서, 다음의 QoS 중심 요건들이 명시되었지만, 대응하는 해결책들이 oneM2M 아키텍처 또는 프로토콜 규격들에서 아직 정의되지 않았다:

● oneM2M 시스템은 기반 네트워크들에의 서비스 요구들 내의 M2M 애플리케이션의 QoS 선호의 포함을 지원할 것이다.

● oneM2M 시스템은 서비스 레벨에서 QoS 선호로 서비스 요구들을 인증할 수 있을 것이지만, 서비스 QoS 요구들의 인증 및 허가 또는 협상을 위해 기반 네트워크에의 서비스 요구들 내의 M2M 애플리케이션의 QoS 선호를 통과시킬 것이다.

● oneM2M 시스템은 보증된 비트레이트, 지연, 지연 변화, 손실율 및 에러율 등과 같은, 파라미터들을 특정하는 상이한 QoS-레벨들을 지원할 수 있을 것이다.

● oneM2M 시스템은 M2M 디바이스가 언제 도달될 수 있는지에 관한 기반 네트워크에 의해 제공된 정보를 수신 및 이용할 수 있을 것이다.

● 기반 네트워크로부터 가용할 때, oneM2M 시스템은 M2M 디바이스의 M2M 서비스 운영 상태를 유지하고 기반 네트워크 접속 서비스 상태가 변화할 때 그것을 업데이트할 수 있을 것이다.

QoS 프로토콜들 및 IoT SL 기술들은 oneM2M 규격의 QoS 중심 요건들에 비추어서 도 9와 관련하여 논의된 것과 같은 사용 경우들을 지원하는 것과 관련하여 다음의 가능한 단점들을 갖는다. 첫번째 가능한 단점은 구별된 서비스들(DiffServ) 및 통합된 서비스들(IntServ)과 같은 QoS 프로토콜들이 많은 IoT 네트워크 구축들 내에서 E2E QoS 관리를 지원하기에 적합하지 않다는 것이다. DiffServ와 IntServ 둘 다는 네트워크 라우터들이 각각의 통신 흐름을 위한 상태를 유지하는 것을 필요로 한다. 이 상태는 많은 IoT 라우터들이 일반적으로 가용하지 않은 리소스들(예를 들어, 메모리, MIPS 등)을 요구한다. DiffServ와 IntServ 둘 다는 QoS 관련 제어 정보를 공유 및 유지하기 위해 라우터들 간의 주기적 통신을 요구한다. 이 추가 메시징 오버헤드는 많은 IoT 네트워크들에 적합하지 않다. 많은 IoT 네트워크들은 상이한 유형들의 기반 액세스 네트워크들(예를 들어, 3GPP, 브로드밴드 이더넷, 와이파이, 6LoWPAN 등)을 가로질러 걸치고 상이한 네트워크 제공자들에 의해 운영되는 E2E 통신 경로들을 포함한다. 여기서 언급된 이유들로 인해, 네트워크들 중 일부는 DiffServ 및 IntServ를 지원하도록 잘 설치되지 않는다. DiffServ 및 IntServ 구축들은 한 운영자의 네트워크와 다른 운영자의 네트워크가 서로 (예를 들어, 상이한 라우터 정책들, DiffServ 및 IntServ 프로토콜들 및 특징들을 위한 상이한 레벨들의 지원) 자주 상이할 수 있다. 그러므로 DiffServ 및 IntServ는 운영자 네트워크들을 가로지르기보다는 개별 운영자의 네트워크 내에서만 사용되는 것이 일반적이다. 마지막으로, DiffServ 및 IntServ 프로토콜들은 디바이스들이 지속적인 네트워크 접속을 유지하지 않기 때문에 많은 IoT 네트워크들에서 중요한 도달가능성 스케줄링과 같은 특징들을 지원하지 않는다.

두번째 가능한 단점은 통상적인 IoT SL 기술들은 애플리케이션이 애플리케이션 사용 경우의 요구들을 충족하는 E2E QoS 요건들(예들 들어, 스케줄, 레이턴시, 지터, 에러율, 처리율, 보안 및 비용의 레벨)을 정의하게 하는 방법들이 결여되어 있다는 것이다.

세번째 가능한 단점은 통상적인 IoT SL 기술들은 또한 잠재적으로 상이한 기술 유형들(예를 들어, 3GPP 및 브로드밴드 이더넷)이고 상이한 네트워크 운영자들(예를 들어, Sprint 및 Verizon)에 의해 소유되고 운영될 수 있는 다수의 기반 네트워크들을 가로질러 걸치는 E2E 통신을 적절히 관리하는 방법들이 결여되어 있다는 것이다.

앞서 언급된 단점들을 참조하여, 도 10은 백엔드 애플리케이션들과 디바이스들을 함께 상호 접속하는 다수의 기반 액세스 네트워크 기술 홉들을 가로질러 걸치는 E2E 통신 경로들로 이루어진 전형적인 IoT 네트워크를 도시한다. 예를 들어, 애플리케이션(131)과 디바이스(132) 간의 E2E 통신은 셀룰러(141), 브로드밴드 이더넷(142), 및 와이파이(143)와 같은 3개의 상이한 액세스 네트워크 기술 홉들을 가로지르는 통신을 포함한다. 유사한 예들이 애플리케이션(134)과 디바이스(135) 간의 통신뿐만 아니라, 애플리케이션(137)과 디바이스(138) 간의 통신과 같은 E2E 통신을 위한 다수의 네트워크들을 통하는 통신들에 관련하여 또한 도시된다.

도 10에서 캡처된 구축과 같은 네트워크 구축들에 관련한 가능한 과제들의 예들은 아래와 같다. 제1 예에서, 통상적인 IoT SL 기술들은 그들이 애플리케이션에 의해 정의된 E2E 도달가능성 스케줄이 부합되게 하기 위해 E2E 방식으로 뿐만 아니라 홉-바이-홉 방식으로 서로 정렬되도록 SL 인스턴스들의 도달가능성 스케줄 및 그들의 접속 스케줄들을 기반 네트워크들(UN들)로 조정하는 능력이 결여되어 있다. 결과적으로, SL 인스턴스들 간의 도달가능성 스케줄들의 불일치들이 일어날 수 있다. 이것이 일어날 때, 메시지들의 저장 및 전송과 같은 동작들이 그들이 도달가능하게 될 통신 경로에서 다음의 홉을 대기하는 동안 홉-바이-홉 방식으로 (예를 들어, IoT 게이트웨이들 및 서버들 상에서) SL 인스턴스들에서 발생할 수 있다. 원칙적으로, 저장 및 전송 지연들은 그들이 그것의 요구된 도달가능성 스케줄에 따라 E2E 방식으로 애플리케이션이 IoT 디바이스와 통신하는 것을 막는 경우에 단지 하나의 문제이다.

제2 예에서, 통상적인 IoT SL 기술들은 그들이 홉-바이-홉 상호접속을 위해 사용하는 UN들의 통신 레이턴시를 관리하고 조정하는 능력이 결여되어 있다. 또한 그들은 애플리케이션에 의해 정의된 E2E 레이턴시 예산이 부합될 수 있도록 그들의 홉-바이-홉 레이턴시들을 관리하는 능력이 또한 결여되어 있다. 결과적으로, E2E 레이턴시의 관리는 현재의 IoT SL 기술들에 의해 지원되지 않는 능력이다. 이것은 요구된 레이턴시 예산에 따라 E2E 방식으로 애플리케이션이 IoT 디바이스와 통신하는 것을 막는다.

제3 예에서, 통상적인 IoT SL 기술들은 그들이 서로 간의 홉-바이-홉 상호접속을 위해 사용하는 UN들의 통신 처리율을 관리하고 조정하는 능력이 결여되어 있다. 또한 그들은 애플리케이션에 의해 정의된 E2E 처리율이 부합될 수 있도록 그들의 홉-바이-홉 처리율을 정렬하는 능력이 또한 결여되어 있다. 결과적으로, E2E 처리율의 관리는 현재의 M2M/IoT SL 기술들에 의해 지원되지 않는 능력이다. 이것은 요구된 처리율에 따라 E2E 방식으로 애플리케이션이 M2M/IoT 디바이스와 통신하는 것을 막는다.

제4 예에서, 통상적인 IoT SL 기술들은 SL 메시지들 간의 지연(예를 들어, 지터)의 E2E 변화를 관리하는 능력 및 결국 애플리케이션에 의해 정의된 E2E 지터 예산이 부합될 수 있도록 그들의 홉-바이-홉 지터를 정렬하는 능력이 또한 결여되어 있다. 결과적으로, E2E 지터의 관리는 현재의 IoT SL 기술들에 의해 지원되지 않는 능력이다. 이것은 요구된 지터 예산에 따라 E2E 방식으로 애플리케이션이 M2M/IoT 디바이스와 통신하는 것을 막는다.

제5 예에서, 통상적인 IoT SL 기술들은 E2E 메시징 에러율을 관리하는 능력이 결여되어 있다. 또한 그들은 애플리케이션에 의해 정의된 E2E 에러율이 부합될 수 있도록 그들의 홉-바이-홉 메시징 에러율들을 정렬하는 능력이 또한 결여되어 있다. 결과적으로, E2E 메시징 에러율의 관리는 현재의 M2M/IoT SL 기술들에 의해 지원되지 않는 능력이다. 이것은 요구된 메시징 에러율에 따라 E2E 방식으로 애플리케이션이 M2M/IoT 디바이스와 통신하는 것을 막는다.

위에 언급된 문제들은 애플리케이션과 M2M/IoT 디바이스 간의 E2E 통신 경로가 상이한 유형들의 UN들을 포함하는 다수의 SL 홉들에 걸칠 때뿐만 아니라 이들 UN들이 상이한 네트워크 운영자들에 의해 소유/운영될 때 복잡할 뿐만 아니라 더 그러할 것 같다. 이것은 상이한 UN들을 가로지르는 E2E 방식으로 QoS를 관리하는 것은 관리하는 것이 과제일 수 있는 상이한 네트워크 기술들을 가로지르는 조정을 요구한다는 사실에 기인한다. 유사하게 상이한 운영자 네트워크들을 가로지르는 E2E 방식으로 QoS를 관리하는 것은 이들 운영자들을 가로지르는 조정을 요구한다. SL 홉들, UN들, 또는 상이한 운영자들의 수가 증가함에 따라, 문제들이 될 가능성이 증가한다.

도 11은 QoS를 단-대-단 방식으로 관리하는 메커니즘들을 지원하는 예시적인 시스템(150)을 도시한다. 시스템(150)은 애플리케이션(156)이 온-디맨드 E2E QoS 요건들을 특정하기를 요구하는 사용 경우들과 같은 사용 경우들을 지원하기 위해 사용될 수 있다. 온-디맨드 E2E QoS 요건들은 무엇보다도, 통신의 도달가능성 스케줄, E2E 레이턴시, E2E 처리율, E2E 지터, E2E 에러율, E2E 보안 레벨, 또는 E2E 비용을 포함할 수 있다. 시스템(150)은 근거리 지역과 원거리 지역 UN들(예를 들어, 3GPP(161), 브로드밴드 이더넷(162), 와이파이(163), 또는 6LoWPAN(164))의 다양한 조합을 통해 서로 상호접속된 IoT 서버들(예를 들어, IoT 서버(152)), IoT 게이트웨이들(예를 들어, IoT 게이트웨이(151)), 및 디바이스들(예를 들어, IoT 필드 디바이스(153) 또는 IoT 디바이스(154))를 포함한다. 서버들 및 게이트웨이들 상에 호스트된 것은 IoT SL들(예를 들어, IoT SL(166) 또는 IoT SL(165))의 인스턴스들이다. 백엔드 내의 디바이스들뿐만 아니라 필드 내의 디바이스들 상에 호스트된 것은 서로 통신하는 IoT 애플리케이션들(예를 들어, IoT 디바이스 애플리케이션(155) 및 IoT 애플리케이션(156))이다. 예를 들어, 환자의 IoT 센서 또는 액추에이터와 백엔드 환자 감시 애플리케이션 간의 E2E 통신.

도 11을 계속 참조하면, 시스템(150)은 서비스 계층 관리자(SLCM) 기능(예를 들어, SLCM(157) 또는 SLCM(158)), 애플리케이션 접속 관리자(ACM) 기능(예를 들어, ACM(159) 또는 ACM(160)) 및 기반 네트워크 접속 관리자(UNCM) 기능(예를 들어, UNCM(167), UNCM(168), 또는 UNCM(169))을 포함한다. SLCM과 함께, ACM, 및 UNCM 기능들은 E2E QoS의 지원으로 IoT 디바이스들, 게이트웨이들, 서버들, 및 애플리케이션들의 단-대-단 UN QoS 및 접속을 보다 지능적으로 관리하고 구성하기 위해 서로 상호작용할 수 있다. 대안적으로, 시스템은 이들 기능의 서브셋만을 지원할 수 있다. 예를 들어, 시스템은 단지 SLCM 및 UNCM 기능들만을 지원하고 ACM 기능들을 지원하지 않을 수 있다.

SLCM 기능은 IoT 게이트웨이 또는 서버 플랫폼 상에 호스트된 oneM2M SL과 같은 IoT SL 내에 내장될 수 있다. 또 하나의 예에서, UNCM 기능은 3GPP, 블루투스, 와이파이, 또는 브로드밴드 이더넷과 같은 다양한 유형들의 기반 액세스 네트워크 기술들 내의 기능으로서 지원될 수 있다.

SLCM(157)은 IoT 디바이스 애플리케이션(155)이 예를 들어, IoT SL(152)에의 E2E SL 세션 QoS 요건들을 특정하게 할 수 있다. 이것은 (예를 들어, 애플리케이션이 타깃된 M2M/IoT 디바이스가 그것의 SL 요구들을 서비스하기 위해 도달가능하기를 요구할 때) 하나 이상의 타깃된 종단점들에 대한 요구된 도달가능성 스케줄을 특정하는 애플리케이션을 포함할 수 있다. 그것은 또한 그것의 요구된 E2E 레이턴시 예산(애플리케이션과 타깃된 M2M/IoT 디바이스 간에 이동하기 위해 SL 요구들 및 응답들을 위한 전체적인 라운드 트립 레이턴시)을 특정하는 애플리케이션을 포함할 수 있다. 그것은 또한 그것의 E2E 지터 예산(예를 들어, 애플리케이션과 타깃된 M2M/IoT 디바이스 간에 이동하는 연속하는 SL 메시지들 간의 지연의 허용가능한 변화)을 특정하는 애플리케이션을 포함할 수 있다. 그것은 또한 그것의 E2E 에러율(예를 들어, 애플리케이션과 타깃된 M2M/IoT 디바이스 간에 E2E 통신할 때 허용가능한 에러율)을 특정하는 애플리케이션을 포함할 수 있다. SLCM(157)은 또한 그것의 요구된 E2E 처리율(예를 들어, 애플리케이션과 타깃된 M2M/IoT 디바이스 간의 처리율)을 특정하는 애플리케이션을 포함할 수 있다.

이 정보를 사용하여, SLCM(157)은 SL 등록자들(예를 들어, 애플리케이션들)의 그것의 총체적 집합의 QoS 요건들을 분석하는 것을 지원하고 모든 그것의 등록자들에 대한 E2E QoS 요건들이 만족되도록 그것의 SL 인스턴스의 구성을 온-더-플라이로 수행할 수 있다. 이것을 하기 위해, SLCM(157)은 E2E SL 세션의 통신 경로 내의 SL 홉들의 각각에 대한 도달가능성 스케줄, 통신 레이턴시, 통신 지터, 에러율, 통신 처리율, 보안의 레벨 및 비용의 온-더-플라이 조정을 수행할 수 있다. 예시적인 E2E SL 세션(147)은 SLCM(157) 및 UNCM(167)을 통해 인에이블된 통신에 기초할 수 있다. 이것을 달성하기 위해서, SLCM(157)은 그것의 SL 인스턴스를 다른 SL 인스턴스들과 상호접속하는 UN들 중 하나 이상 내에 호스트된 UNCM 기능들과 협력할 수 있다. 이 협력은 SLCM(157)이 UNCM(167)에 SL 중심 콘텍스트 정보를 제공하는 것을 포함할 수 있고, 결국 UNCM(167)이 그것의 대응하는 기반 액세스 네트워크와 연관된 접속들을 관리할 수 있다. 콘텍스트는 애플리케이션(예를 들어, IoT 디바이스 애플리케이션(155)) 또는 SL(예를 들어, IoT SL(166)) 특정된 도달가능성 스케줄(들), 애플리케이션 또는 SL 특정된 최대 통신 레이턴시(단일-홉 및/또는 단-대-단), 애플리케이션 또는 SL 특정된 처리율(단일 홉 및/또는 단-대-단), 애플리케이션 또는 SL 특정된 지터, 애플리케이션 또는 SL 특정된 에러율, 및 보안 및 비용의 레벨을 포함할 수 있다.

ACM(160)은 예를 들어, IoT 디바이스 애플리케이션(155)의 E2E SL 세션 QoS 요건들을 결정하기 위해 IoT 디바이스 애플리케이션(155)에 의해 사용될 수 있다. IoT 디바이스 애플리케이션(155)은 다음에 그것의 로컬 IoT SL(166)에 의해 호스트된 SLCM(157)에 이들 요건을 전달할 수 있다. ACM(160)은 E2E SL 세션을 셋업할 때 이것을 할 수 있다. 이들 요건은 하나 이상의 타깃된 종단점들에 대한 IoT 디바이스 애플리케이션(155) 특정 도달가능성 스케줄, 요구된 E2E 레이턴시 예산, 및 요구된 E2E 처리율, IoT 디바이스 애플리케이션(155) 특정된 지터, 비용 레벨들, 보안 레벨들 및 IoT 디바이스 애플리케이션(155) 특정된 에러율을 포함할 수 있다. ACM(160)은 유사한 요건들을 공유하기 위해 브로드밴드 이더넷(167)(기반 네트워크)에 의해 호스트된 UNCM(167)과 또한 통신할 수 있다.

UNCM(167)은 예를 들어, SL 인스턴스들이 대응하는 UN(예를 들어, 브로드밴드 이더넷(162))에의 접속 스케줄, 레이턴시, 지터, 에러율, 처리율, 보안 및 비용의 레벨과 같은 그들의 UN QoS 요건들을 특정하게 하는 기능성을 지원할 수 있다. 이 정보는 다음에 지정된 SL 인스턴스들 또는 SL 세션과 연관된 SL 메시지들이 SL 정의된 요건들에 부합하는 방식으로 브로드밴드 이더넷(162)에 의해 처리될 수 있도록 예를 들어, UN 구성을 조정하기 위해 브로드밴드 이더넷(162)에 의해 사용될 수 있다.

UNCM(167)은 또한 SL 인스턴스들(예를 들어, IoT SL(166))로 UN 중심 정보를 되 전달하기 위해 브로드밴드 이더넷(162)에 의해 사용될 수 있다. 예를 들어, UNCM(167)은 특정한 SL 세션(예를 들어, SL 세션(147))에 관한 정보를 SLCM(157)에 제공할 수 있다. 이 정보를 SLCM(157)과 공유하는 것은 UNCM(167)이 단-대-단 통신뿐만 아니라 애플리케이션들 및 SL(들)의 도달가능성 스케줄들을 보다 지능적으로 관리하게 할 수 있다. 이 정보는 피어 SL 인스턴스 또는 애플리케이션에 대한 UN 접속 내의 네트워크 혼잡 또는 변화들을 포함할 수 있다. 예를 들어, SLCM(157)은 UNCM(167)에 의해 제공된 브로드밴드 이더넷(167)의 혼잡 정보에 기초하여 SL 세션(147)에 대해 하나의 UN(예를 들어, 브로드밴드 이더넷(162))으로부터 또 하나의 UN(예를 들어, 3GPP(161))으로 전환하는 결정을 취할 수 있다.

무엇보다도, 도 12 - 도 17에 도시된 단계들을 수행하는 엔티티들은 도 30c 또는 도 30d에 도시된 것들과 같은 디바이스, 서버, 또는 컴퓨터 시스템의 메모리 내에 저장되고, 프로세서 상에서 실행하는 소프트웨어(예를 들어, 컴퓨터 실행가능 명령어들)의 형태로 구현될 수 있는 논리적 엔티티들이라는 것이 이해된다. 즉, 무엇보다도, 도 12 - 도 17에 도시된 방법(들)은 컴퓨팅 시스템의 프로세서에 의해 실행될 때, 여기의 무엇보다도, 도 12 - 도 17에 도시된 단계들을 수행하는, 도 30c 또는 도 30d에 도시된 디바이스 또는 컴퓨터 시스템과 같은 컴퓨팅 디바이스의 메모리 내에 저장된 소프트웨어(예를 들어, 컴퓨터 실행가능 명령어들)의 형태로 구현될 수 있다. 한 예에서, M2M 디바이스들의 상호작용과 관련하여 아래에 더 상세히 설명하자면, 도 11의 IoT 디바이스 애플리케이션(155)은 도 30a의 M2M 단말 디바이스(18) 상에 상주할 수 있고, 도 11의 SLCM(157) 및 SLCM(158)은 도 30a의 M2M 게이트웨이 디바이스(14) 상에 상주할 수 있다.

도 12는 IoT 디바이스들, 게이트웨이들, 및 서버들 사이에서 조정된 E2E 방식으로 UN QoS를 관리하기 위해 사용될 수 있는 SLCM 기능 및 UNCM 기능에 대한 예시적인 메시지 흐름을 도시한다. 단계 170에서, 전제 조건 동작들이 있다. 예를 들어, UN 접속이 각각의 디바이스, 게이트웨이, 및 서버 사이에서 확립된다. 각각의 개별적인 홉(E2E는 아님)에 대한 엔티티들 간에 크리덴셜들 및 인증을 확립하는 것과 같은 적절한 SL 보안 절차들이 수행된다. SL 등록이 애플리케이션들과 그들의 로컬 SL들 사이뿐만 아니라 SL 인스턴스들 사이에서 수행된다. 디바이스들, 리소스들, 및 서비스들의 발견이 애플리케이션들에 의해 수행된다. 단계 171에서, 애플리케이션(156)은 그것이 하나 이상의 디바이스 애플리케이션과 통신하기를 원한다고 결정한다. 사용 경우 요건들에 기초하여, 애플리케이션(156)은 그 자체와 타깃된 디바이스 애플리케이션(예를 들어, IoT 디바이스 애플리케이션(155)) 사이의 E2E QoS 요건들을 결정한다. 예를 들어, 무엇보다도, E2E 통신 스케줄(예를 들어, 하루 중의 시간), E2E 통신 레이턴시(예를 들어, 라운드 트립 지연은 정의된 임계를 초과하지 않아야 한다), E2E 지터(예를 들어, 센서 판독들 간의 지연의 변화는 정의된 임계를 초과하지 않는다), E2E 에러율(예를 들어, 센서 판독 메시지들의 E2E 에러율은 정의된 임계를 초과하지 않는다), 또는 E2E 처리율(예를 들어, 초당 센서 판독들)이다.

도 12를 계속 참조하면, 단계 172에서, 애플리케이션(156)은 그 자체와 IoT 디바이스 애플리케이션(155) 사이에 E2E SL 세션을 확립하기 위해 (IoT 서버(151) 상에 호스트될 수 있는) IoT SL(165)에 요구를 송신한다. 단계 172의 요구는 애플리케이션(156)이 단계 171에서 정의한 E2E QoS 요건들을 포함한다. 단계 173에서, SLCM(158)은 UN들이 E2E SL 세션에 대해 특정된 QoS 요건을 충족하는 구성을 필요로 하는지를 체크한다. SLCM(158)은 E2E SL 세션 ID를 할당하고 다음의 SL 홉을 또한 결정한다. IoT 서버(151) 상에 호스트된 IoT SL(165)과 연계된 SLCM(158)은 그것의 현재 구성 및 그것의 UN들(예를 들어, 3GPP(161), 와이파이(163), 또는 브로드밴드 이더넷(162))의 구성이 무엇보다도, 도달가능성 스케줄, 레이턴시, 지터, 에러율, 처리율, 보안 레벨, 또는 비용에 대해 정의된 E2E SL 세션 정의된 QoS 요건들에 맞을 수 있는지 여부를 결정한다. SLCM(158)은 또한 유일한 SL 세션 ID를 도출한다. 단계 174a 및 단계 174b에서, SLCM(158)은 3GPP(161) 또는 브로드밴드 이더넷(162)(또는 다른 UN)이 단계 172에서 요구된 E2E SL 세션의 QoS 요건들을 충족하도록 재구성될 수 있는지(또는 이미 구성된 것인지)를 결정하기 위해 SLCM(158)을 그것의 다음의 홉 E2E SL 세션 파트너들과 접속할 수 있는 UN들의 각각 내의 UNCM(168) 또는 UNCM(167)과 협력한다.

도 12를 계속 참조하면, 단계 175a 및 단계 175b에서, 3GPP(161)의 UNCM(168) 및 브로드밴드 이더넷(162)의 UNCM(167)은 무엇보다도, 도달가능성 스케줄, 레이턴시, 지터, 처리율, 에러율, 보안의 레벨, 또는 비용 관리를 제어하는 것을 담당하는 다른 UN 기능들과 조정한다. 이렇게 하는데 있어서, 각각의 UNCM은 UN이 E2E SL 세션에 의해 정의된 특정된 QoS 설정들로 E2E SL 세션과 연계된 메시지들을 처리할 수 있는지 여부를 결정한다. 단계 176에서, IoT 서버(151) 상에 호스트된 SL 인스턴스(IoT SL(165))는 세션 요건들에 맞을 수 있는 UN(예를 들어, 브로드밴드 이더넷(162))을 선택하고 E2E SL 세션 확립 요구를 IoT 게이트웨이(152) 상에 호스트된 SL 인스턴스(IoT SL(166))인 다음의 SL 홉에 전송한다. SL 세션 ID는 단계 176의 이 요구 내에 포함된다.

도 12를 계속 참조하면, 단계 177에서, SLCM(157)은 UN들이 E2E SL 세션에 대해 특정된 QoS 요건들을 충족하는 구성을 필요로 하는지를 체크한다. SLCM(157)은 또한 다음의 SL 홉을 결정한다. IoT 게이트웨이(152) 상에 호스트된 IoT SL(166)과 연계된 SLCM(157)은 그것의 현재 구성 및 그것의 게이트웨이-디바이스 UN들의 구성이 E2E SL 세션 QoS 요건들에 맞을 수 있는지 여부를 결정한다. 본 예에서, 요건들이 맞을 수 있다. 단계 174a 및 단계 174b와 유사하게, 단계 178a 또는 단계 178b에서, SLCM(157)은 6LoWPAN(164)이 단계 172에서 요구된 E2E SL 세션의 QoS 요건들을 충족하도록 재구성될 수 있는지(또는 이미 구성된 것인지)를 결정하기 위해 SLCM(157)을 그것의 다음의 홉 E2E SL 세션 파트너들과 접속할 수 있는 6LoWPAN(164)의 UNCM(149)과 협력한다. 단계 175a 또는 단계 174와 유사하게, 단계 179a 또는 단계 179b에서, 3GPP(161)의 UNCM(168) 및 브로드밴드 이더넷(162)의 UNCM(167)은 무엇보다도, 도달가능성 스케줄, 레이턴시, 지터, 에러율, 처리율, 보안의 레벨, 또는 비용 관리를 제어하는 것을 담당하는 다른 UN 기능들과 조정한다. 이렇게 하는데 있어서, 각각의 UNCM은 UN이 E2E SL 세션에 의해 정의된 특정된 QoS 설정들로 E2E SL 세션과 연계된 메시지들을 처리할 수 있는지 여부를 결정한다. 단계 180에서, IoT 게이트웨이(152) 상에 호스트된 IoT SL(166)은 세션 요건들을 충족할 수 있는 6LoWPAN(164)를 선택하고 E2E SL 세션 확립 요구를 타깃된 E2E SL 세션 종단점(예를 들어, IoT 디바이스 애플리케이션(155))을 향하는 다음의 SL 홉(들)에 전송한다. 단계 180의 요구는 E2E SL 세션 ID를 포함할 수 있다. 대안적으로 IoT 게이트웨이(152) 상에 호스트된 SL 인스턴스는 IoT 디바이스 애플리케이션을 대신하여 프록시하고 IoT 디바이스 애플리케이션(155)을 대신하여 이 요구를 서비스하는 것을 처리할 수 있다.

도 12를 계속 참조하면, 단계 181에서, IoT 디바이스 애플리케이션(155)은 E2E SL 세션 확립 요구를 수신하고 처리한다. IoT 디바이스 애플리케이션(155)이 요구의 발신자(예를 들어, IoT 애플리케이션(156))로 E2E SL 세션 내로 합류하기를 동의하면 IoT 디바이스 애플리케이션(155)은 요구를 수용함으로써 응답한다. 그렇지 않으면 그것은 요구를 거절하는 에러를 반환한다. 응답은 대응하는 요구에서 특정된 SL 세션 ID를 포함한다. IoT 애플리케이션(155)은 IoT 디바이스 애플리케이션(155)이 E2E SL 세션 확립 요구를 수용했다는 것을 표시하는 응답을 수신한다. 단계 182에서, IoT 애플리케이션(156)은 다음에 IoT 디바이스 애플리케이션(155)과 통신하라는 E2E SL 세션 요구를 발생한다. 단계 182의 요구를 생성할 때, IoT 애플리케이션(156)은 E2E 세션 ID를 포함할 수 있다. 이 E2E 세션 ID는 E2E SL 세션 확립 동안 구성된 E2E QoS 설정들이 충족되도록 요구를 적절히 처리하기 위해 E2E 통신 경로 내의 UN들 및 SL 인스턴스들에 의해 사용될 수 있다. 예를 들어, UN은 (예를 들어, 깊은 패킷 검사 기술을 사용하여) 메시지 내의 E2E SL 세션 ID 마커를 검출하고 이 SL 세션 ID를 사용하여 그것이 유지하는 E2E SL 세션 QoS 요건들에 기초하여 메시지를 처리한다. 단계 183에서, IoT 디바이스 애플리케이션(155)은 단계 182의 요구를 수신하고 다음에 IoT 애플리케이션(156)으로 되돌아 가는 E2E SL 세션 응답을 발생한다. 단계 183의 응답을 생성할 때, IoT 디바이스 애플리케이션은 E2E 세션 ID를 포함할 수 있다. 이 E2E 세션 ID는 E2E SL 세션 확립 동안 구성된 E2E QoS 설정들이 충족되도록 응답을 적절히 처리하기 위해 E2E 통신 경로 내의 UN들 및 SL 인스턴스들에 의해 사용될 수 있다.

표 2는 E2E SL 세션들의 처리를 지원하기 위해 제공될 수 있는 (예를 들어, SL 세션 확립 요구 내에 포함되는) 여러가지 예시적인 유형들의 SL 중심 정보 요소들을 개시한다. 각각의 E2E SL 세션은 SL QoS 정보뿐만 아니라 그것과 연관된 UN QoS 관련 정보 둘 다를 가질 수 있다. 이 정보는 SL 세션의 각각의 홉 사이의 UN QoS 뿐만 아니라 SL 세션 종단점들 간의 단-대-단 SL QoS를 관리하기 위해 사용될 수 있다. 이 정보는 (예를 들어, SLCM 기능들을 사용하는) SL들, (예를 들어, UNCM 기능들을 사용하는) UN들뿐만 아니라 SL 세션 종단점들에 의해 수집, 유지, 또는 공유될 수 있다.

표 2의 정보 요소들은 SL 세션 발신자(예를 들어, IoT 디바이스 애플리케이션(156))가 그 자체와 하나 이상의 다른 타깃된 SL 세션 종단점들 간의 E2E QoS 요건들을 정의하게 할 수 있다. 마찬가지로, SL은 이 정보를 사용하여 SL 세션 발신자의 E2E QoS 요건들을 결정하고 결국 여기에 개시된 방법들을 사용하여 그들을 만족시키도록 시도할 수 있다.

표 3은 E2E SL QoS의 지원으로 사용될 수 있는 여러가지 유형들의 UN 중심 정보 요소들을 제안한다. 예를 들어, E2E SL 세션 내의 각각의 통신 홉에 대해, SL 확립 요구를 시작하거나 전송하는 엔티티는 이 정보를 (예를 들어, 그것을 요구 자체 내에 포함시킴으로써) 가용하게 할 수 있다. 이 정보는 또한 SL 자체 또는 UN들에 의해 수집, 추적, 및 유지될 수 있다. 또한, 소정의 경우들에서 SL 및 UN들은 서로 협력하고 (예를 들어, SLCM 또는 UNCM을 통해) 이 정보를 교환할 수 있다. 본 개시내용은 이것을 지원하는 방법들을 제안한다.

도 13은 IoT 필드 디바이스(153)(예를 들어, IoT 센서), IoT 게이트웨이(152), IoT 서버(151), 및 IoT 애플리케이션(156) 상에 호스트된 애플리케이션들 사이에 확립되는 0-홉(186), 1-홉(187), 및 2-홉(188) E2E SL 세션들의 사용 경우 예들을 도시한다. 이들 경우 각각에서, IoT 애플리케이션(156)은 E2E SL 세션의 확립을 시작한다. 0-홉(186)에서, IoT 애플리케이션(156)은 IoT 서버(151)와의 E2E SL 세션을 확립한다. 1-홉(187)에서, IoT 애플리케이션(156)은 IoT 게이트웨이(152)와의 E2E SL 세션을 확립한다. 2-홉(188)에서, IoT 애플리케이션(156)은 IoT 필드 디바이스(153) 상에 호스트된 애플리케이션과의 E2E SL 세션을 확립한다.

도시한 사용 경우들의 확립되는 3개의 E2E SL 세션들에서, IoT 서버(151) 및 IoT 게이트웨이(152) 상에 호스트된 SL들에 의해 지원된 각각의 SLCM 기능은 UN들에 의해 지원된 각각의 UNCM 기능과 통신할 수 있다. 이렇게 하는데 있어서, SLCM들 및 UNCM들은 E2E SL 세션의 E2E QoS 요건들을 충족할 수 있도록 E2E SL 세션의 각각의 홉을 위해 사용된 UN QoS의 적절한 선택 및 구성을 조정한다.

E2E SL QoS 요건들을 만족시키기 위해 UN QoS를 관리하는 방법들이 여기에 개시된다. 구체적으로, 이들 방법은 E2E SL 세션 확립, E2E SL 세션 통신, 및 E2E SL 세션 해체 동안 UN QoS를 관리하는 것을 포함한다.

도 14는 E2E SL 세션 확립 동안에 UN QoS를 관리하는 예시적인 방법을 도시한다. 도 14에 도시한 절차의 전제 조건은 SL 등록자(예를 들어, IoT 애플리케이션(156))가 그 자체와 타깃된 SL 세션 종단점(예를 들어, IoT 디바이스 애플리케이션(155)) 사이의 SL 세션의 확립에 대한 요구를 발생하는 것이다. 이 요구에서, IoT 애플리케이션(156)은 표 2에서 특정된 SL 중심 정보 및 아마도 적용가능한 경우에, 표 3에서 특정된 액세스 네트워크 중심 정보와 같은 요구 내에 정보를 포함시킴으로써 E2E SL 세션에 대한 그것의 QoS 요건들을 특정할 수 있다. E2E SL 세션 확립 요구가 SL 등록자의 로컬 SL에 의해 수신되는 점은 도 14에서 정의된 절차가 시작하는 점이다. 이 절차는 그것이 타깃된 SL 세션 종단점을 향해 전파됨에 따른 E2E SL 세션 확립 요구뿐만 아니라 그것이 요구를 발신한 SL 등록자를 향해 되돌아오는 흐름에 따른 대응하는 응답을 처리하기 위해 사용된다. 제안된 절차의 상세한 단계들이 아래에 정의된다. 단계 201에서, 수신기(예를 들어, IoT 서버(165), IoT 게이트웨이(152), 또는 IoT 디바이스 애플리케이션(155)과 같은, 중간 SL 인스턴스 또는 타깃된 SL 세션 종단점)는 들어오는 요구를 검출하고 그것이 SL 세션 확립 요구 또는 응답인지 여부를 체크한다. 이 체크는 SL 메시지 내의 헤더 정보를 분석함으로써 수행될 수 있다. 헤더 정보는 SL 메시지의 SL 메시지 유형을 표시할 수 있다. 단계 201의 수신된 SL 메시지가 SL 세션 확립 요구이면, 단계 202로 간다. 단계 201의 수신된 SL 메시지가 SL 세션 확립 응답이면, 그것은 단계 211로 진행한다.

도 14를 계속 참조하면, 단계 202 및 단계 203에서 단계 201의 SL 메시지가 SL 세션 확립 요구이면, 수신기의 SLCM은 아래에 논의되는 바와 같이, 무엇보다도, SL 도달가능성 스케줄 체크, UN 접속 체크, SL 홉 레이턴시 체크, SL 홉 처리율 체크, SL 홉 지터 체크, SL 홉 에러율 체크, SL 홉 비용 레벨 체크, 또는 SL 홉 보안 레벨 체크와 같은, QoS 체크들 및 그 자체와 그것의 이웃하는 SL 세션 홉 파트너 간의 가능한 정렬을 수행할 수 있다. 체크들을 하기 전에 SLCM은 E2E SL 세션이 이미 존재하는지를 검증하는 체크를 수행할 수 있다는 점에 주목한다. SL 도달가능성 스케줄 체크 - SL 도달가능성 스케줄들을 체크하고 정렬하기 위해, 수신기의 SLCM 또는 ACM은 그것의 현재의 SL 도달가능성 스케줄을 요구에서 특정된 E2E SL 세션 도달가능성 스케줄과 비교한다. 이 체크는 수신기의 SL이 활성이고 새로운 SL 세션이 확립되기 위해 요구되는 시간들 동안 SL 메시지들을 처리하기 위해 도달가능한지를 검증하는 것이다. 이것을 하기 위해, 수신기의 SLCM 또는 ACM은 현재의 도달가능성 스케줄 윈도우(들)가 요구에서 특정된 것들과 정렬되는지(또는 정렬되지 않는지)를 체크한다. 이것은 요구에서 특정된 각각의 도달가능성 윈도우의 시작 및 종료 시간들을 수신기의 현재의 도달가능성 윈도우들의 시작 및 종료 시간들과 비교함으로써 행해질 수 있다. UN 접속 체크 - UN 접속 스케줄들을 체크하고 정렬하기 위해, 수신기의 SLCM 또는 ACM은 그것이 그것의 도달가능성 윈도우들 각각에 대해 지원하는 상이한 유형들의 UN들을 새로운 SL 세션에 의해 요구된 것들과 비교할 수 있다. 이들은 요구에서 특정될 수 있고 또는 요구자가 이 정보를 미리 수신기에 가용하게 할 수 있다. 이 정보를 그렇게 미리 수신기에 가용하게 하는데 있어서, 수신기의 SLCM 또는 ACM은 적어도 하나의 공통 UN이 활성이고 SL 세션에 대해 요구되는 각각의 도달가능성 윈도우에 대해 수신기와 그것의 이웃하는 SL 세션 홉 파트너(들) 간의 필요한 접속을 제공하는지 여부를 체크할 수 있다.

도 14의 단계들 202-203을 계속 참조하면, SL 홉 레이턴시 체크 - 수신기의 SLCM 또는 ACM은 가용한 경우에 UNCM으로부터 이 특정한 SL 홉에 대한 레이턴시 정보를 획득할 수 있다. UNCM으로부터 가용하지 않으면, SLCM 또는 ACM은 그것이 들어오는 요구에서 특정된 요구된 E2E SL 세션 레이턴시보다 적은지를 결정하기 위해 그 자체와 그것의 이웃하는 SL 세션 홉 파트너 간의 통신 레이턴시를 비교함으로써 레이턴시 체크들을 수행할 수 있다. 이 체크를 수행하기 위해 수신기의 SLCM 또는 ACM은 그것이 그것의 이웃하는 SL 세션 홉 파트너(들)를 향해 타깃하고 대응하는 응답들을 되 수신할 수 있는 하나 이상의 별개의 SL 핑 요구들(또는 기타)을 자동 발생할 수 있다. 레이턴시를 측정하기 위해, SLCM 또는 ACM은 각각의 SL 핑이 송신되는 시간 및 응답이 수신되는 시간을 측정할 수 있다. SLCM 또는 ACM은 레이턴시를 계산하기 위해 다음에 감산하고 평균할 수 있다. 하나 보다 많은 UN들이 수신기와 그것의 이웃하는 SL 세션 홉 파트너(들)를 접속하면, SLCM 또는 ACM은 각각의 UN에 대해 이 레이턴시 체크를 수행하고 이들을 비교하여 SL 세션 레이턴시 요건들을 충족하는 최상의 UN을 선택할 수 있다. SLCM 또는 ACM은 또한 이들 레이턴시 측정을 유지하고 그것이 자주 레이턴스 측정들을 반복할 필요가 없도록 그들을 미래의 SL 세션 요구들을 위해 재사용할 수 있다. SLCM 또는 ACM은 또한 레이턴시가 SL 세션 레이턴시 요건에 계속 충족하는지를 모니터하기 위해 이 레이턴시 체크를 주기적으로 재수행할 수 있다. 그렇지 않으면, SLCM 또는 ACM은 이것을 표시하기 위해 발신 SL 세션 종단점에 에러 또는 이벤트를 신호할 수 있다. SL 홉 처리율 체크 - 수신기의 SLCM 또는 ACM은 가용한 경우에 UNCM으로부터 처리율 정보를 획득할 수 있다. 가용하지 않으면, SLCM 또는 ACM은 그것이 들어오는 SL 세션 확립 요구에서 특정된 요구된 E2E SL 세션 처리율과 일치하거나 초과하는지를 결정하기 위해 그 자체와 그것의 이웃하는 SL 세션 홉 파트너 사이의 통신 처리율을 비교함으로써 처리율 체크들을 수행할 수 있다. 이 체크를 수행하기 위해 수신기의 SLCM은 그것이 그것의 이웃하는 SL 세션 홉 파트너(들)를 향해 타깃하고 대응하는 응답들을 되 수신할 수 있는 SL 핑 요구들의 반복된 시퀀스를 자동 발생할 수 있다. SLCM은 SL 세션 확립 요구에서 특정된 최대 SL 메시지 크기에 맞도록 각각의 핑의 길이를 구성할 수 있다. 처리율을 측정하기 위해, SLCM은 그것이 응답들을 수신하는 속도를 측정할 수 있다. 하나 보다 많은 UN들이 수신기와 그것의 이웃하는 SL 세션 홉 파트너(들)를 접속하면, SLCM은 각각의 UN에 대해 이 처리율 체크를 수행하고 이들을 비교할 수 있다. SLCM은 또한 이들 처리율 측정들을 유지하고 그것이 자주 측정들을 반복할 필요가 없도록 그들을 미래의 SL 세션 요구들을 위해 재사용할 수 있다. SLCM 또는 ACM은 또한 처리율 SL 세션 레이턴시 요건에 계속 충족하는지를 모니터하기 위해 이 처리율 체크를 주기적으로 재수행할 수 있다. 그렇지 않으면, SLCM 또는 ACM은 이것을 표시하기 위해 발신 SL 세션 종단점에 에러 또는 이벤트를 신호할 수 있다.

도 14의 단계들 202-203을 계속 참조하면, SL 홉 지터 체크 - 수신기의 SLCM 또는 ACM은 가용한 경우에 UNCM으로부터 지터 정보를 획득할 수 있다. 가용하지 않으면, SLCM 또는 ACM은 처리율 체크에서 위에 설명된 것과 유사한 절차를 사용하여 지터 체크를 수행할 수 있다. 처리율을 측정하는 것 대신에, SLCM 또는 ACM은 연속하는 핑 응답들 간의 지연의 변화를 측정할 수 있다. SL 홉 에러율 체크 - 수신기의 SLCM 또는 ACM은 가용한 경우에 UNCM으로부터 에러율 정보를 획득할 수 있다. 가용하지 않으면, SLCM 또는 ACM은 처리율 체크와 관련하여 여기서 설명된 것과 유사한 절차를 사용하여 에러율 체크를 수행할 수 있다. 처리율을 측정하는 것 대신에, SLCM 또는 ACM은 핑 요구들 및 응답들의 시퀀스에 대한 에러율을 측정할 수 있다. SL 홉 비용 레벨 체크 - 수신기의 SLCM 또는 ACM은 가용한 경우에 UNCM으로부터 비용 정보를 획득하고 UN을 사용하는 비용이 E2E SL 세션 요건들과 정렬되는지를 결정하기 위해 이것을 요구에서 특정된 비용 요건들(예를 들어, 예산)과 비교할 수 있다. SL 홉 보안 레벨 체크 - 수신기의 SLCM 또는 ACM은 가용한 경우에 UNCM으로부터 보안 정보를 획득하고, UN 내의 보안의 지원된 레벨들 중 어느 것이 E2E SL 세션 요건들과 정렬되는지를 결정하기 위해 이것을 요구에서 특정된 보안 요건들과 비교할 수 있다.

도 14를 계속 참조하면, 단계 204에서, 수신기의 SLCM 또는 ACM은 단계 203에서 체크들을 못한 QoS 파라미터들을 (있다면) 조정하기를 시도한다. SLCM 또는 ACM은 (지원되는 경우) 각각의 해당 UN 내의 UNCM들과 협력함으로써 수신기와 그것의 이웃하는 SL 세션 홉 파트너(들) 간에 UN들 내의 QoS 파라미터들을 조정하기를 시도한다. 이것을 하기 위해, SLCM 또는 ACM은 그것이 하나 이상의 UNCM에 송신하는 요구를 생성할 수 잇다. 이 요구에서, SLCM 또는 ACM은 E2E SL 세션 ID, 수신기 및 그것의 이웃하는 SL 세션 홉 파트너의 UN 어드레스들, 및 수신기와 그것의 이웃하는 SL 세션 홉 파트너 간의 요구된 UN QoS 파라미터와 같은 유형들의 정보를 포함할 수 있다(각각의 표 2 및 표 3에 대한 정의들 참조).

도 14의 단계 204를 계속 참조하면, 이 정보를 사용하여, UNCM은 수신기와 그것의 이웃하는 SL 세션 홉 파트너(들) 간의 QoS 요건들(예를 들어, 스케줄, 레이턴시, 지터, 에러율, 처리율, 비용, 보안)을 결정할 수 있다. UNCM은 다음에 SL 세션 QoS 요건들을 충족하도록 UN을 구성하는 것이 가능한지를 결정하기 위해 UN 내의 다른 기능들과 조정할 수 있다. 이것은 이 UN에 걸쳐 수신기와 그것의 이웃하는 SL 세션 홉 파트너 간에 일어나는 모든 SL 통신에 대해 행해질 수 있거나, 대안적으로 그것은 이 특정한 SL 세션과 연관되고 이 특정한 E2E SL 세션 ID로 마크된 메시지들에 대한 UN만에 의해 선택적으로 행해질 수 있다. SL 도달가능성 스케줄 조정 또는 UN 접속 스케줄 조정과 같은, 일부 QoS 파라미터 특정 조정 절차들이 아래에 논의된다. SL 도달가능성 스케줄 조정 - SL 도달가능성 스케줄이 서로 정렬되지 않으면, 수신기의 SLCM 또는 ACM은 그들을 정렬하기를 시도하기 위해 수신기의 SL 도달가능성 윈도우(들)을 조정하기를 시도할 수 있다. 이것을 하기 위해, 수신기의 SLCM 또는 ACM은 임의의 다른 기존의 SL 세션들에 영향을 주지 않도록 주의하여야 한다. 이것은 SLCM 또는 ACM이 그것의 현재의 SL 세션들에 대해 요구되는 수신기의 기존의 SL 도달가능성 윈도우들을 확립되고 있는 새로운 SL 세션에 의해 요구된 도달가능성 윈도우와 집합시킴으로써 달성될 수 있다. 그렇게 하는데 있어서, SLCM 또는 ACM은 모든 SL 세션들이 (예를 들어, 세션 스케줄들을 서로 정렬하거나 하지 않음으로써) 서로 공존하는 것을 보장할 수 있다. UN 접속 스케줄 조정 - 적절한 UN 접속이 존재하지 않는 경우들에 대해, SLCM 또는 ACM은 UN 접속 스케줄들을 E2E SL 세션 요건들과 정렬하기 위해 그들을 수정하기를 시도하기 위해 각각의 해당 UN 내의 UNCM들과 통신할 수 있다. 이것을 하기 위해, SLCM 또는 ACM은 그것이 UNCM에 송신하는 요구를 생성할 수 있다. 이 요구에서, SLCM 또는 ACM은 수신기 및/또는 그것의 이웃하는 SL 세션 홉 파트너에 대한 SL 세션 ID 및 접속 스케줄과 같은 정보를 포함할 수 있다. UNCM은 다음에 그들이 SL 세션 통신을 위해 요구되는 시간들 동안 서로 정렬하도록 접속 스케줄들을 수정하기를 시도하기 위해 다른 UN 기능들과 조정하기 위해 이 정보를 사용할 수 있다. 위에 설명된 접속 스케줄 체크 및 정렬 동작들이 성공하면, 절차는 레이턴시 체크들을 수행하는 것으로 진행하고, 그렇지 않으면 수신기가 적절한 접속이 수신기와 그것의 이웃하는 SL 세션 홉 파트너(들) 간에 확립되지 않은 것을 표시하는 에러 응답을 준비하여 송신하는 단계 210로 진행한다. 도움이 될 수 있는 추가의 정보를 제공하기 위해, 달성가능한 스케줄이 이 에러 응답에서 반환될 수 있다.

도 14를 계속 참조하면, 단계 205에서, 요구된 QoS 파라미터 조정이 성공하면, 절차는 타깃된 SL 세션 종단점이 원격으로 호스트되는지 여부를 체크하는 단계 206으로 진행하고, 그렇지 않으면 수신기가 요구된 QoS가 맞지 않을 수 있다는 것을 표시하는 에러 응답을 준비하고 송신하는 단계 210으로 진행한다. 도움이 될 수 있는 추가의 정보를 제공하기 위해, 달성가능한 QoS 파라미터 값들이 이 에러 응답에서 반환될 수 있다. 단계 206에서, 수신기의 SLCM 또는 ACM이 SL 세션을 확립하기 위해 요구에서 특정된 타깃된 SL 세션 종단점이 로컬로 호스트되는지 또는 또 하나의 홉에 전송되어야 하는지를 체크한다. 이것은 수신기들 어드레스를 타깃된 SL 세션 종단점의 어드레스와 비교함으로써 행해질 수 있다. 요구가 또 하나의 SL 홉에 전송되어야 한다면, 절차는 전송될 요구를 준비하는 단계 207로 진행한다. 그렇지 않으면 절차는 SL 세션 확립 응답을 준비하는 단계 209로 진행한다. 요구는 단-대-단 서비스 계층 세션이 확립될 때까지 하나의 서비스 계층 노드로부터 또 하나의 서비스 계층 노드로 전송될 수 있다. 단계 207에서, 타깃된 SL 세션 종단점이 수신기에 의해 호스트되지 않기 때문에 SL 세션 확립 요구가 다음의 홉에 전송된다. 요구를 전송하기 전에, 수신기의 SLCM 또는 ACM은 E2E QoS 예산 중 얼마나 많은 것이 소비할 후속하는 홉들에 대한 레이턴시, 지터, 및 에러율과 같은 소정의 QoS 파라미터에 대해 남아 있는지를 표시하기 위해 요구를 업데이트할 수 있다. 이것을 하기 위해, 수신기의 SLCM 또는 ACM은 그것의 홉에 의해 소비된 측정된 QoS 파라미터를 요구에 유지된 E2E SL 세션 값으로부터 감산할 수 있다. 그렇게 하는데 있어서, 다음의 홉이 요구를 수신할 때 각각의 QoS 파라미터에 대한 남아 있는 예산이 E2E 통신 경로에서 이전의 홉들을 고려하도록 조정되었을 것이다.

도 14를 계속 참조하면, 단계 208에서, E2E SL 세션 확립 요구가 다음의 홉에 전송된다. 단계 209에서, 타깃된 SL 세션 종단점이 수신기에 의해 호스트된다. 이 요구를 수신할 때, 수신기는 타깃이 존재한다는 것을 검증하고 발신 SL 세션 종단점이 타깃과의 E2E SL 세션을 확립하기 위해 적절한 허용들을 갖는다는 것을 검증하는 것과 같은 동작들을 수행할 수 있다. 수신기는 성공적인 SL 세션 확립 응답을 형식화할 수 있다. 응답은 E2E SL 세션 ID, 성공적인 응답 코드, 또는 홉-바이-홉 E2E SL 계층 세션 확립 동안 측정된 것과 같은 측정된 E2E QoS 파라미터들과 같은 정보를 포함할 수 있다. 측정된 E2E QoS 파라미터들은 홉-바이-홉 E2E SL 계층 세션 동안 측정된 최소의 처리율뿐만 아니라 남아 있는 레이턴시, 지터, 비용, 및 에러율 예산들과 같은 측정들을 포함할 수 있다. 이 응답은 다음에 그것이 그로부터 요구를 수신하는 수신기의 동일한 이웃하는 SL 세션 홉 파트너에 되 송신된다. 이 응답을 수신할 때, 이웃하는 SL 세션 홉 파트너는 이 동일한 절차를 사용하여 응답을 처리할 수 있다(단계 211 참조). 단계 210에서, 수신기는 E2E SL 세션 확립 요구를 성공적으로 처리할 수 없었다. 수신기는 에러 응답을 그것이 그로부터 수신한 그것의 동일한 이웃하는 SL 세션 홉 파트너에 반환할 수 있다. 이 응답을 수신할 때, 이웃하는 SL 세션 홉 파트너는 이 동일한 절차를 사용하여 응답을 처리할 수 있다(단계 211 참조).

도 14를 계속 참조하면, 단계 211에서, 수신기의 SLCM은 그것이 성공적인 응답인지 에러인지를 결정하기 위해 E2E SL 세션 확립 응답을 체크한다. 그것이 성공적인 응답이면 절차는 단계 213으로 진행한다. 그렇지 않으면 절차는 단계 212로 진행한다. 에러 응답의 경우에, 단계 212에서, SL 세션 상태가 삭제된다. 수신기 SLCM은 그것이 유지하는 SL 세션 상태를 제거하고 또한 그들이 SL 세션 상태 및 구성을 해체하게 하도록 지원하는 기반 네트워크들에서 각각의 UNCM과 또한 통신한다. 이것은 E2E SL 세션 확립 처리 동안 구성된 SL 세션에 기초하는 UN 접속, 레이턴시, 지터, 에러율 및 처리율 구성을 제거하는 것을 포함할 수 있다. 단계 213에서, 수신기는 그것이 수신기가 가질 수 있는 어떤 미결의 E2E SL 세션 확립 요구들과 일치하는지를 결정하기 위해 SL 세션 ID를 체크하는 것에 기초하여 그것이 E2E SL 세션 발신 종단점인지를 체크한다. 그것이 일치하면, 수신기는 E2E SL 세션 확립 요구가 성공적이었는지 여부를 결정하기 위해 응답을 처리한다. 그렇지 않으면, 절차는 응답을 다음의 홉에 전송하는 단계 215로 진행한다. 단계 214에서, E2E SL 세션이 E2E SL 발신 종단점에 의해 성공적으로 확립된다고 간주된다. 단계 215에서, 수신기의 SLCM 또는 ACM은 응답이 그것을 E2E SL 세션 발신 종단점을 향하는 방향으로 하도록 이 세션에 대한 그것의 대응하는 이웃하는 SL 세션 홉 파트너에 E2E SL 세션 응답을 전송한다.

도 15는 E2E SL 세션 메시지들을 송신하는 동안에 UN 접속들을 관리하는 예시적인 방법을 도시한다. 확립될 때, E2E SL 세션은 E2E SL 세션 통신 요구들 및 응답들을 송신 및 수신하기 위해 사용될 수 있다. 단계 221에서, E2E SL 세션 참여자(예를 들어, SL 세션 종단점 또는 중간 SL 인스턴스)는 그것이 이미 확립된 특정한 E2E SL 세션을 통해 E2E SL 세션 통신 요구 또는 E2E SL 세션 통신 응답 메시지를 송신할 필요가 있다고 결정한다. 단계 222에서, E2E SL 세션을 통해 응답을 송신하기 위해, 참여자는 응답을 생성하고 요구에서 특정된 E2E 세션 ID에 맞도록 E2E 세션 ID를 구성한다. 응답은 애플리케이션 특정 응답 정보와 같은 것뿐만 아니라 다른 정보를 포함할 수 있다. 응답에 대한 타깃된 목적지가 SLCM에 의해 결정된다. 이것을 하기 위해 SLCM 또는 ACM은 그것이 (아래 단계 223에서 설명되는 것과 같이) 시작 또는 리타깃하는 각각의 및 모든 E2E SL 세션 요구에 대해 그것이 유지하는 로컬 상태를 사용한다. E2E SL 세션 ID를 사용하여, SLCM 또는 ACM은 그것이 응답을 어디에 송신하여야 하는지를 찾는다. 단계 223에서, E2E SL 세션을 통해 요구를 송신하기 위해, 참여자는 요구를 생성하고 그것이 타깃하고 있는 E2E SL 세션 종단점으로의 목적지 어드레스를 구성한다. 그것은 또한 그것이 타깃된 종단점과 통신하기 위해 사용하기를 원하는 SL 세션에 대응하는 E2E 세션 ID를 포함한다. 요구는 애플리케이션 특정 요구 정보와 같은 것뿐만 아니라 다른 정보를 포함할 수 있다. 요구를 송신할 때, SLCM 또는 ACM은 요구에 대한 SL 세션 상태를 유지한다. SLCM 또는 ACM은 그것이 요구를 발신하는지 또는 그것이 요구를 리타깃하는지를 유지한다. 그것이 요구를 리타깃하는 경우에 대해, SLCM은 또한 그것이 리타깃될 요구를 수신하는 어떤 SL 엔티티를 추적한다. 이 정보는 E2E SL 세션 ID를 사용하는 것으로 추적된다.

도 15를 계속 참조하면, 단계 224에서, E2E SL 세션 통신 요구/응답이 타깃된(요구의 경우에) 또는 발신하는(응답의 경우에) E2E SL 세션 종단점을 향해 라우트될 필요가 있다. 그래서, SLCM 또는 ACM에 대해 이 과정에 포함된 동작들 중 하나는 그것을 라우트할 다음의 SL 홉을 결정하기 위해 E2E SL 세션 통신 요구/응답에서 특정된 목적지 어드레스를 분석하는 것일 수 있다. 이것은 다음의 SL 홉을 결정하기 위해 SLCM 또는 ACM이 요구/응답 내에 포함된 E2E SL 세션 ID를 SL 라우팅 상태와 비교하는 것을 포함할 수 있다. 이것은 다음의 홉 SL의 IP 어드레스와 같은 라우트가능한 어드레스를 생성할 수 있다. 이 라우트가능한 어드레스는 다음에 UN 어드레스로 분해될 수 있다. 단계 225에서, 메시지는 다음에 SLCM 또는 ACM으로부터 E2E SL 세션 확립 동안 할당된 대응하는 UN으로 핸드 오프된다. UN이 이 메시지를 수신할 때 그것은 UN이 인식하는 E2E SL 세션 ID 마커를 그것이 포함하는지 여부를 결정하도록 메시지를 분석하기 위해 그것의 UNCM 기능을 사용할 수 있다. 예를 들어, UNCM은 메시지를 분석하고 UNCM이 E2E SL 세션 확립 동안 함께 구성된 E2E SL 세션 ID들을 찾기 위해 깊은 패킷 검사(DPI) 기술들을 사용할 수 있다. 단계 226에서, UN이 SL 세션 인식 방식으로 메시지들을 처리하는 것을 지원하지 않는 경우에 대해 또는 현재의 메시지가 UN에 의해 인식가능한 E2E SL 세션 ID를 포함하는 경우에 대해, UN은 비-SL 세션 인식 방식으로 메시지를 처리할 수 있다. 이 경우에, SL은 E2E QoS가 달성되는 것을 보장하는 것을 담당한다. 그것은 UN이 SL에 가용하게 하는 UN QoS 정보를 사용하여 그렇게 할 수 있다. SL은 결국 E2E QoS가 유지되는 것을 보장하기 위해 조정을 할 수 있다(예를 들어, UN들을 변화시킬 수 있다).

단계 227에서, UN이 SL 세션 인식 방식으로 메시지들을 처리하는 것을 지원하고 현재의 메시지가 그것이 인식하는 E2E SL 세션 ID를 포함하지 않는다는 것을 검출한 경우에 대해, UNCM 기능은 메시지를 SL 세션 인식 방식으로 처리할 수 있다. 이것을 하는데 있어서, UNCM 기능은 이 메시지와 연관된 E2E SL 세션 ID를 UN 내의 다른 기능들에 알릴 수 있다. 이 정보를 사용하여, 다른 기능들은 E2E SL 세션 QoS 요건들이 맞을 수 있도록 하는 방식으로 메시지를 처리할 수 있다. 예를 들어, UN은 그것이 네트워크에 접속할 목적지를 트리거하여 그것이 메시지를 그것에 송신할 수 있을 때를 제어함으로써 메시지의 스케줄링을 제어할 수 있다. 유사하게, UN은 다양한 UN 기능들을 통해 통과하는 동안 메시지가 일으키는 지연들을 제어함으로써 메시지의 레이턴시, 지터 및 처리율을 제어할 수 있다. 단계 228에서, UN의 UNCM(지원되는 경우)은 E2E SL 세션 통신 요구/응답 메시지의 처리에 관해 SLCM에 피드백(또는 통지들)을 제공할 수 있다. 이 피드백은 UN이 E2E SL 세션 확립 동안 보고된 동일한 QoS 레벨들에 맞을 수 있었는지 여부 및 새로운 측정들이 이 주어진 메시지를 위한 것인지 여부를 포함할 수 있다. 이 피드백은 또한 특정된 에러율 임계가 초과되었는지 여부를 포함할 수 있다. 예를 들어, UN이 혼잡하게 되고 SL 세션 확립 중에 구성된 SL 세션 요건들에 더 이상 맞지 않을 수 있다면, UNCM은 SLCM 또는 ACM에 통지할 수 있다. 단계 229에서, 메시지 바이 메시지 기초, 주기적 기초, 또는 이벤트 기초로 (예를 들어, 메시지를 처리할 때 그것은 SL 세션의 요건들에 맞지 않는 레이턴시 또는 처리율을 초래함) UN 정보를 SLCM 또는 ACM과 공유하면 SLCM 또는 ACM이 이 특정한 UN이 계속 유지하고 E2E SL 세션의 QoS 요건들을 충족하는지 여부를 추적할 수 있다. 그 경우에 대해, SLCM 또는 ACM이 이것이 그 경우가 아니라는 것을 검출한 경우에, SLCM 또는 ACM은 UN이 이 과제를 해결하기 위해 UN 네트워크 기능들을 재구성하기를 시도하는 것을 요구하는 것과 같은 교정 조치를 취할 수 있다(예를 들어, SL 세션 메시지들의 우선순위를 높인다). 대안적으로, SLCM 또는 ACM은 또한 사용하기 가용한 또 하나의 가용한 UN이 있는지를 결정하기 위해 체크할 수 있고 그렇다면, 그것은 E2E SL 세션을 이 새로운 UN으로 이동시킬 수 있다. 이것을 하기 위해, SLCM 또는 ACM은 그것이 E2E SL 세션 확립 절차에서 원래의 UN으로 하는 것처럼 새로운 UN 내의 새로운 UNCM에 동일한 유형의 요구를 송신할 수 있다. 유사하게, 그것은 E2E SL 세션 해체 절차에서 설명된 것과 같이 이 세션을 해체하기 위해 오래된 UN 내의 오래된 UNCM에 요구를 송신할 수 있다. 성공적이면, SLCM 또는 ACM은 그것이 이 특정한 E2E SL 세션에 대해 수신한 미래의 E2E SL 세션 통신 요구/응답 메시지들을 처리하기 위해 새로운 UN을 사용하기 시작할 수 있다.

도 16은 E2E SL 세션 메시지들을 수신하는 동안 UN QoS를 관리하는 예시적인 방법을 도시한다. 단계 231에서, 수신기의 SLCM 또는 ACM(예를 들어, 발신 SL 세션 종단점, 중간 SL 인스턴스 또는 타깃된 SL 세션 종단점)은 들어오는 SL 메시지를 검출하고 그것이 SL 세션 통신 요구 또는 응답인지 여부를 체크한다. 이 체크는 그것의 SL 메시지 유형을 표시하는 SL 메시지 내의 헤더 정보를 분석함으로써 수행된다. 그것이 SL 세션 통신 요구 또는 응답이면 단계 232로 진행한다. 그것이 어느 것도 아니면 절차는 끝난다. 단계 232에서, 수신기의 SLCM 또는 ACM은 그것이 SL 세션 통신 요구 또는 응답인지를 체크한다. 단계 233에서, 수신기의 SLCM 또는 ACM은 SL 세션 통신 요구에서 특정된 타깃된 종단점이 로컬로 호스트되는지 또는 요구가 또 하나의 홉에 전송되어야 하는지를 체크한다. 이것은 수신기들 어드레스를 타깃된 SL 세션 종단점의 어드레스와 비교함으로써 행해질 수 있다. 단계 234에서, 요구가 또 하나의 SL 홉으로 리타깃되어야 한다면, 수신기의 SLCM은 그렇게 하기 위해 도 15에서 정의된 절차를 사용할 수 있다. 단계 235에서, SL 세션 통신 요구가 수신기를 타깃하는 것을 검출한 후에, 수신기는 요구를 처리할 수 있다(예를 들어, 수신기에 의해 호스트된 리소스로 CRUD 동작을 수행하고, 또는 수신기에 의해 호스트된 타깃된 기능을 호출하는 것 등이다). 수신기는 애플리케이션 특정 응답 정보를 포함할 수 있는 응답을 (적용가능한 경우에) 다음에 계산할 수 있다. 단계 236에서, 수신기의 SLCM 또는 ACM은 SL 세션 통신 응답 메시지를 발생한다. 이 응답에서, 수신기의 SLCM 또는 ACM은 응답이 그것이 발신기로 다시 라우트됨에 따라 중간 SL들 및 UN들에 의해 E2E SL 세션 메시지로서 처리될 수 있도록 SL 세션 통신 요구로부터의 동일한 E2E SL 세션 ID를 포함하는 것을 확실하게 한다. 응답을 송신하기 위해, 수신기의 SLCM 또는 ACM은 도 15에서 정의된 절차를 사용할 수 있다.

도 16을 계속 참조하면, 단계 237에서, 수신기의 SLCM 또는 ACM은 수신기가 이 응답에 대응하는 요구의 발신자인지를 결정하기 위해 SL 세션 통신 응답을 체크한다. 이것을 하기 위해, 수신기는 응답 내의 E2E SL 세션 ID를 그것이 발신하거나 그것이 리타깃하는 각각의 SL 세션 통신 요구에 대해 그것이 유지하는 그것의 로컬로 저장된 상태와 비교한다. 수신기가 SL 세션 ID가 수신기가 시작한 요구와 일치하는 것을 검출하면, 수신기는 그것이 응답을 리타깃할 필요가 없고 수신기는 자체적으로 응답을 처리하여야 한다는 것을 안다. 수신기가 E2E SL 세션 ID가 그것이 리타깃한 요구와 일치한다는 것을 검출하면, 수신기는 그것이 그로부터 요구를 수신한 동일한 SL 엔티티(예를 들어, 중간 SL 인스턴스 또는 SL 세션 발신 종단점)에 다시 응답을 리타깃할 필요가 있다는 것을 안다. 수신기가 E2E SL 세션 ID를 인식하지 않으면, 그것은 응답을 포기하고 절차는 끝난다. 단계 218에서, 수신기는 수신된 응답과 대응하는 SL 세션 통신 요구의 발신자이다. 수신기는 응답을 처리하고 그것으로부터 애플리케이션 특정 응답 정보를 추출한다. 단계 219에서, 수신기는 수신된 응답과 대응하는 SL 세션 통신 요구의 발신자가 아니고, 그래서 수신기의 SLCM은 응답을 다음의 홉에 전송한다. 이것을 하기 위해, 수신기의 SLCM은 그렇게 하기 위해 도 15에서 정의된 절차를 사용할 수 있다.

도 17은 E2E SL 세션 해체 동안에 UN 접속들을 관리하는 예시적인 방법을 도시한다. 도 17에 도시한 절차의 전제 조건은 SL 등록자(예를 들어, 백엔드 애플리케이션)가 그 자체와 타깃된 SL 세션 종단점(예를 들어, 디바이스 애플리케이션) 간의 E2E SL 세션을 해체하라는 요구를 발생하는 것일 수 있다. 이 요구에서, SL 등록자는 타깃된 세션 종단점뿐만 아니라 E2E SL 세션 ID를 특정한다. 다음에 이 요구는 처리하기 위해 SL 등록자의 로컬 SL에 전송된다. E2E SL 세션 해체 요구가 SL 등록자의 로컬 SL에 의해 수신되는 점은 도 17에서 정의된 절차가 시작하는 점이다. 이 절차는 그것이 타깃된 SL 세션 종단점을 향해 홉-바이-홉으로 전파됨에 따라 E2E SL 세션 해체 요구를 처리하기 위해 사용될 수 있다. 이 절차는 또한 그것이 요구를 발신한 SL 등록자를 향해 다시 흐름에 따라 대응하는 E2E SL 세션 해체 응답을 처리하는 것일 수 있다. 단계 241에서, 수신기의 SLCM 또는 ACM(예를 들어, 발신 SL 세션 종단점, 중간 SL 인스턴스 또는 타깃된 SL 세션 종단점)은 들어오는 SL 메시지를 검출하고 그것이 SL 세션 해체 요구 또는 응답인지 여부를 체크한다. 이 체크는 그것의 SL 메시지 유형을 표시하는 SL 메시지들 내의 헤더 정보를 분석함으로써 수행된다. 그것이 어느 것도 아니면, 절차는 끝난다. 단계 242에서, 수신기의 SLCM 또는 ACM은 그것이 E2E SL 해체 요구의 타깃인지를 체크한다. 단계 243에서, 요구가 수신기를 타깃하지 않으면, 수신기는 다음의 홉으로의 E2E SL 해체 요구를 리타깃한다. 이것을 하는데 있어서, 수신기의 SLCM은 그것이 요구를 리타깃하는 상태를 유지하고 그것은 리타깃될 요구를 수신한 어떤 SL 엔티티를 추적한다. 이 정보는 E2E SL 세션 ID를 사용하는 것으로 추적된다.

도 17을 계속 참조하면, 단계 244에서, 요구가 수신기를 타깃하면, SLCM 또는 ACM은 먼저 SLCM 또는 ACM이 응답을 수신하고 그것이 세션을 해체하는 것에 동의하는 것을 표시하는 E2E SL 세션 해체 응답을 발생함으로써 요구를 처리한다. 단계 245에서, 응답을 송신하기 위해, 참여자는 응답을 생성하고 요구에서 특정된 E2E 세션 ID와 일치하도록 E2E 세션 ID를 구성한다. 응답은 애플리케이션 특정 응답 정보와 같은 다른 정보를 포함할 수 있다. 타깃된 목적지는 요구에서 특정된 E2E SL 세션 발신자이다. 단계 246에서, 수신기의 SLCM 또는 ACM은 E2E SL 세션 확립 동안 또는 E2E SL 세션 통신 동안 생성된 어떤 상태를 삭제한다. SCLM 또는 ACM은 UN 내에 유지된 상태를 삭제하고 이 특정한 홉에 대한 E2E SL 세션을 서비스할 필요가 있는 확보된 리소스들을 자유롭게 하기 위해 적용가능한 UN들 각각 내에 상주하는 UNCM들과 또한 통신한다. 이것은 해체되고 있는 세션과 일치하는 E2E SL 세션 ID를 갖는 연계된 메시지들의 E2E SL 세션 인식 처리를 위해 사용된 UN 기능들 중 어느 것에 대한 구성을 포함한다. 단계 247에서, 들어오는 메시지가 E2E SL 세션 해체 응답인 경우에 대해, 수신기의 SLCM 또는 ACM은 응답이 수신기가 발신한 E2E SL 세션 해체 요구와 상관하는지를 체크한다. 단계 248에서, 아니오이면, 수신기의 SLCM은 응답을 전송할 다음의 홉을 결정한다. 이것을 하기 위해 SLCM은 그것이 리타깃하는 E2E SL 세션 해체 요구들에 대해 그것이 유지하는 로컬 상태를 사용한다. E2E SL 세션 ID를 사용하여, SLCM은 그것이 이 E2E SL 세션 ID와 일치하는 대응하는 E2E SL 세션 해체 요구를 어디에서 수신하는지를 찾는다.

단계 249에서, 응답은 다음에 SLCM 또는 ACM으로부터 E2E SL 세션 확립 동안 할당된 대응하는 UN으로 핸드 오프된다. UN은 다음에 메시지를 다음의 홉에 전송한다. 단계 250에서, 수신기의 SLCM 또는 ACM은 E2E SL 세션 확립 동안 또는 E2E SL 세션 통신 동안 생성된 상태를 삭제한다. SCLM 또는 ACM은 이 특정한 홉에 대한 E2E SL 세션을 서비스할 필요가 있는 UN 내에 유지된 상태를 삭제하기 위해 적용가능한 UN들 각각 내에 상주하는 UNCM들과 또한 통신한다. 이것은 해체되고 있는 세션과 일치하는 E2E SL 세션 ID를 갖는 연계된 메시지들의 E2E SL 세션 인식 처리를 위해 사용된 UN 기능들 중 어느 것에 대한 구성을 포함한다. 단계 251에서, 응답이 수신기가 발신한 E2E SL 세션 해체 요구와 상관하면, 수신기는 타깃된 E2E SL 세션 종단점에 의해 성공적으로 세션 해체가 처리된 것을 검증하기 위해 응답을 처리한다. 단계 252에서, 수신기의 SLCM 또는 ACM은 다음에 (지원되는 경우에) E2E SL 세션 확립 동안 또는 E2E SL 세션 통신 동안 생성된 상태를 삭제한다. SCLM 또는 ACM은 이 특정한 홉에 대한 E2E SL 세션을 서비스할 필요가 있는 UN 내에 유지된 어떤 상태를 삭제하기 위해 적용가능한 UN들 각각 내에 상주하는 UNCM들과 또한 통신한다. 이것은 해체되고 있는 세션과 일치하는 E2E SL 세션 ID를 갖는 연계된 메시지들의 E2E SL 세션 인식 처리를 위해 사용된 UN 기능들 중 어느 것에 대한 구성을 포함한다.

도 18은 SLCM이 oneM2M 정의된 서비스 세션 관리(SSM) CSF의 지원된 기능으로서 실현되는 예를 도시한다. 이 SLCM 인에이블된 SSM CSF(272)는 IoT 디바이스(예를 들어, ASN-CSE(271)), IoT 게이트웨이(예를 들어, MN-CSE(273)), 또는 IoT 서버(IN-CSE(275)) 상에 호스트된 oneM2M CSE들에 의해 지원된다.

이 SLCM 인에이블된 SSM CSF(272)는 결국 oneM2M 정의된 네트워크 서비스 노출, 서비스 실행 및 트리거(NSSE) CSF(예를 들어, NSSE CSF(278))를 통해 UNCM과 인터페이스한다. UNCM 기능(예를 들어, UNCM(276))은 3GPP 정의된 서비스 능력 노출 기능(SCEF), 예를 들어, SCEF(277)의 기능으로서 실현된다. SCEF(277)는 결국 3GPP 네트워크(예를 들어, 3GPP 네트워크(274)) 내의 다양한 다른 기능들과 인터페이스한다. oneM2M의 정의에 따라, SCEF(277)는 기반 네트워크 서비스들 엔티티(NSE)이다. 도 18에서, E2E oneM2M SL 세션이 2개의 상이한 네트워크 운영자들에 의해 소유된 3GPP 네트워크들을 가로질러 걸치는 다수의 CSE 홉들에 의해 분리된 2개의 oneM2M AE들(예를 들어, AE(270)와 AE(279)) 사이에 확립된다. 각각의 oneM2M AE는 ACM 기능을 지원한다. SLCM과 함께, ACM 및 UNCM 기능들은 oneM2M AE들이 애플리케이션 특정 QoS 요건들로 E2E oneM2M SL 세션을 서로 확립하게 한다. SLCM, ACM, 및 UNCM 기능들의 지원을 통해, oneM2M CSE들은 상이한 운영자들에 의해 소유된 2개의 기반 3GPP 네트워크들과 뿐만 아니라 서로 조정할 수 있다. 이 조정을 통해, QoS 파라미터들의 적절한 조정들 및 정렬들이 oneM2M 서비스 계층 및 기반 3GPP 네트워크들 둘 다에서 달성될 수 있다. 그렇게 하는데 있어서, AE들의 E2E QoS 요건들은 궁극적으로 본 개시내용에서 포착된 제안된 방법들을 사용하여 홉 바이 홉 기초로 그리고 E2E 기초로 조정된 CSE들에 의해 관리될 수 있다. 결과적으로, oneM2M AE들은 그들의 특정된 E2E QoS 요건들을 충족하는 방식으로 E2E oneM2M SL 세션을 사용하여 서로 통신할 수 있다.

API는 AE가 E2E oneM2M SL 세션을 확립하게 하기 위해 oneM2M SSM CSF에 대해 정의될 수 있다. API는 리소스 정의들(예를 들어, RESTful API)에 기초할 수 있다. 통상적인 리소스들은 <session>, <sessionPolicy>, 및 <sessionContext>를 포함할 수 있다. 향상들이 E2E SL 세션의 확립 동안, 애플리케이션 특정 E2E QoS 요건들을 AE가 정의하게 하는 <session> 및 <sessionPolicy> 리소스들에 대해 이루어질 수 있다. 여기에 개시된 API 향상들은 oneM2M SLCM 또는 ACM API를 실현하기 위해 사용될 수 있다. E2E SL 세션 발신자(예를 들어, AE(270) 또는 IoT 디바이스 애플리케이션(155))가 각각 그것의 로컬 CSE 내에서 이들 리소스를 생성 또는 삭제하게 함으로써 E2E SL 세션의 확립 또는 해체를 요구하기 위해 사용될 수 있는 일부 향상들이 아래에 논의된다. 또한, 이들 리소스는 또한 E2E SL 세션을 홉 바이 홉 방식으로 확립 또는 해체하기 위해 중간 CSE들에 의해 사용될 수 있다. 이것은 각각, E2E SL 세션의 확립 또는 해체 동안 다음-홉 CSE 상에서 이들 리소스를 생성 또는 삭제하는 중간 CSE에 의해 행해질 수 있다. 그렇게 하는데 있어서, 멀티-홉 E2E SL 세션 구성 내의 각각의 CSE는 각각의 E2E SL 세션에 대해 이들 리소스의 대응하는 세트를 유지할 수 있다. 이들 리소스는 CSE에 그것이 지원을 돕는 각각의 E2E SL 세션에 대한 상태를 유지하는 인식 및 능력을 제공한다.

도 19는 oneM2M <session> 리소스에 대한 예시적인 향상들을 도시한다. 이것은 AE가 특정한 oneM2M E2E SL 세션과 연관된 애플리케이션 특정 E2E QoS 요건들을 정의하게 하는 다수의 속성들을 포함한다. 속성들은 표 4에 정의되고 도 19에 도시한 것과 같은 schedule, latency, jitter, errorRate, throughput, costLevel, 및 securityLevel 속성들일 수 있다. 또 하나의 예에서, <session> 리소스 내에 정의된 E2E SL 세션 QoS 요건들 대신에 그들은 대신에 도 20에 도시한 것과 같은 oneM2M <sessionPolicy>에서 정의될 수 있다.

통상적으로, oneM2M은 그것에 등록된 CSE와 AE들 또는 다른 CSE들 간의 접속을 제공하는 UN들에 관한 QoS 중심 정보를 유지하는 리소스를 정의하지 않는다. 예를 들어, 도 21에 도시된 것과 같은 <UN> oneM2M 리소스가 여기에 개시된다. 이 리소스는 개별적인 UN으로부터 공개 또는 검색될 수 있는 정보를 추적하고 유지하는 속성들의 세트를 지원한다. CSE는 각각의 지원된 UN에 대한 별도의 <UN> 리소스를 지원하고 이 리소스를 사용하여 UN에 관한 정보를 유지한다. 이 유형의 정보를 지원하는 것은 그것이 UN 인식 결정들을 하게 할 수 있는 CSE에 UN 콘텍스트(예를 들어, 이 UN에 걸치는 AE 또는 CSE의 현재의 도달가능성, 통신 레이턴시, 및 통신 처리율)의 가시성을 제공한다. 예를 들어, CSE는 이 정보에 기초하여 이웃하는 CSE 또는 AE와의 통신에 가용한 UN들의 세트를 랭크하고 가장 최적한 사용을 결정할 수 있다. 리소스 내에 유지된 정보는 무엇보다도, UN을 통해(예를 들어, 3GPP 네트워크와 연계된 SCEF에 의해 지원된 UNCM 기능을 통해) 공개되거나, (예를 들어, CSE에 의해 지원된 SLCM을 통해) UN으로부터 검색될 수 있다. 표 5는 예시적인 속성들을 제공한다.

통상적으로, oneM2M은 <AE>와 <remoteCSE> 리소스들 둘 다를 위한 단일 pointOfAccess 속성을 정의한다. 통상적인 속성은 대응하는 AE 또는 CSE에 대한 UN 어드레스들의 리스트를 포착하기 위해 사용된다. AE 또는 CSE가 또 하나의 등록기 CSE에 등록할 때, 그것은 이 정보를 제공할 수 있다. 이 정보는 메시지를 그것에 송신할 필요가 있을 때 AE 또는 CSE에 접촉하기 위해 등록기 CSE에 의해 사용될 수 있다. 통상적으로, oneM2M은 IP 어드레스들의 리스트 또는 FQDN들 및 포트들로서 pointOfAccess 속성 내에 저장된 정보를 정의한다. AE 또는 CSE에 의해 지원된 각각의 대응하는 UN은 이 리스트 내에 엔트리를 갖는다. 정의된 것과 같은 pointOfAccess 속성은 기타 UN 정보를 지원하지 않는다.

CSE에 추가의 UN 정보의 가시성을 제공하기 위해 oneM2M pointOfAccess 속성에의 제안된 향상들이 아래에 정의된다. 도 22는 예시적인 E2E SL 세션 QoS 요건들 <pointOfAcess> 속성을 도시한다. 제1 예시적인 향상에서, pointOfAccess 속성은 그 자신의 개별적인 속성들을 갖는 리소스들로 변환될 수 있다. 이것을 하는 것은 그들이 추가의 UN 정보를 특정하게 하는 CSE와 그것의 등록자들 간의 더 많은 도움이 되는 API를 생성한다.

제2 예시적인 향상에서, 추가의 UN QoS 관련 정보에 대한 지원이 표 3에 개시된 정보와 같이, 추가될 수 있다. CSE에 등록된 주어진 AE 또는 CSE에 대한 이 정보를 지원하는 것은 등록기 CSE에 UN 특정 구성 및 주어진 AE 또는 CSE에 대한 요건들의 가시성을 제공한다. 이것은 그것의 등록자들 각각에 관한 UN 특정 정보를 갖는 등록기 CSE를 가능하게 할 수 있다. 예를 들어, CSE는 그것에 등록된 각각의 AE 또는 CSE에 대해, 그 AE 또는 CSE와의 통신에 가용한 UN들의 세트를 결정할 수 있다. 별개로, CSE는 각각의 AE 또는 CSE에 대한 UN 요건들을 갖는다. 이 정보는 다음에 특정한 AE 또는 CSE와 통신할 때 어떤 UN을 사용할지에 대한 결정이 보다 잘 알려지게 하기 위해 사용될 수 있다. 표 6은 도 22와 연관된 예시적인 속성들을 제공한다.

도 23 및 도 24는 <AE> 리소스 및 <remoteCSE> 리소스에 대한 예시적인 <pointOfAccess> 차일드 리소스를 도시한다. 여기서 <AE> 또는 <remoteCSE> oneM2M 리소스는 예를 들어, 도 23 또는 도 24에 도시한 것과 같은 개시된 <pointOfAccess> 리소스의 별개의 인스턴스들을 지원하는 것이 허용될 수 있다. <pointOfAccess>의 별개의 인스턴스는 그 자체와 그것의 등록기 CSE 사이의 접속을 제공하는 각각의 UN에 대한 그것의 접속 정보룰 유지하기 위해 AE 또는 CSE에 의해 생성될 수 있다.

3GPP 정의된 SCEF에 의해 지원될 수 있는 UNCM 기능을 위한 API가 여기에 개시된다. 이 개시된 API는 성질에 있어서 RESTful이고 신뢰된 애플리케이션 또는 제3자 서비스에 의해(예를 들어, oneM2M CSE에 의해 지원된 SLCM 기능에 의해) 액세스될 수 있는 리소스들 및 속성들의 세트를 정의한다.

도 25는 3GPP UNCM/SCEF에 대한 예시적인 <UNCM> 리소스를 도시한다. 이 리소스는 UN 정보를 추적하고 유지하기 위해 속성들의 세트를 지원한다. UNCM은 그것이 지원하는 각각의 UN에 대한 별개의 <UNCM> 리소스를 지원할 수 있다. <UNCM>은 그것이 다음에 이 리소스를 통해 가용하게 하는 정보를 수집하기 위해 각각의 해당 UN 내의 대응하는 UN 노드들/기능들과 통신하는 것을 지원할 수 있다. UNCM은 신뢰된 애플리케이션 또는 서비스 제공자가 UNCM으로부터 UN 정보를 수신하게 하기 위해 가입 메커니즘뿐만 아니라 이 리소스에의 검색 요구들을 지원할 수 있다. 예를 들어, SLCM 기능은 <UNCM> 리소스를 검색할 수 있거나 그것은 <UNCM> 속성들 중 어느 것이 업데이트되는 경우에 통지를 수신하기 위해 가입을 생성할 수 있다. 표 7은 예시적인 <UNCM> 리소스 속성들 및 차일드 리소스들을 제공한다.

도 26은 3GPP UNCM/SCEF에 대한 예시적인 <UNCMSession> 리소스를 도시한다. 이 리소스는 신뢰된 애플리케이션 또는 서비스 제공자가 SL 세션에 대응하는 UNCM에 의해 관리된 UN 내에 통신 세션을 생성하게 하기 위해 속성들의 세트를 지원한다. 예를 들어, oneM2M CSE 내의 SLCM 기능은 그 자체와 이웃하는 CSE 간에 단일 홉 UN 세션을 확립하기 위해 <UNCMSession> 리소스를 생성할 수 있다. 본 개시내용에서 제안된 E2E SL 세션 ID를 갖는 <UNCMSession> 리소스의 sessionID 속성을 구성함으로써, SLCM은 E2E 세션의 하나의 홉을 확립할 수 있다. 이 과정은 다수의 UN 세션들로 이루어진 E2E SL 세션을 형성하기 위해 E2E SL 세션 내의 각각의 홉에 대해 반복될 수 있다. sessionID를 구성하는 것 외에, SLCM은 또한 다른 속성들을 E2E SL 세션 QoS 요건들(스케줄, 레이턴시, 및 처리율)과 정렬하기 위해 다른 속성들을 구성할 수 있다. UNCM은 결국 UN이 세션을 생성할 수 있는지에 기초하여 성공 또는 실패 응답으로 응답할 수 있다. 성공적인 경우에, UNCM은 sessionID 및 QoS 요건들로 해당 노드들을 구성할 수 있다. 이것은 UN이 QoS 요건들에 정렬되는 방식으로 sessionID를 포함하는 임의의 메시지들을 검출 및 처리하게 한다. SLCM은 또한 세션을 해체하기 위해 <UNCMSession>을 삭제하는 것뿐만 아니라 QoS 요건들을 변경하기 위해 <UNCMSession> 리소스를 업데이트할 수 있다. 표 8은 예시적인 <UNCMSession> 리소스 속성들 및 차일드 속성들을 제공한다.

도 27은 오픈플로우에 기초한 소프트웨어 정의된 네트워킹(SDN) 시스템의 예를 도시하고 여기서 오픈플로우 가능한 스위치들 또는 라우터들은 IoT 디바이스, 게이트웨이, 서버 및 백엔드 애플리케이션을 상호접속한다. 오픈 플로우 스위치 규격 1.3.4, 2014년 3월 24일, https://www.opennetworking.org/ja/sdn-resources-ja/onf-specifications/openflow 및 오픈 플로우 제어기-스위치 1.0, 2014년 8월 15일, https://www.opennetworking.org/ja/sdn-resources-ja/onf-specifications/openflow를 참조할 수 있고, 이 둘 다는 그 전체가 참조로 포함된다.

도 27을 계속 참조하면, 각각의 오픈플로우 가능한 스위치 또는 라우터는 UNCM 기능으로 인에이블된다. 이 UNCM 기능은 M2M/IoT 게이트웨이와 서버 둘 다에 의해 호스트된 M2M/IoT SL에 의해 지원된 SLCM 기능에 인터페이스한다. SLCM 기능은 오픈-플로우 가능한 스위치 또는 라우터 상에서 구현되는 UNCM과 통신하기 위해 오픈플로우 제어기 기능들을 호출할 수 있다.

본 예에서, E2E oneM2M SL 세션은 다수의 기반 오픈플로우 가능한 스위치들 또는 라우터들을 가로질러 걸치는 다수의 M2M/IoT 서비스 계층 홉들에 의해 분리된 2개의 애플리케이션들 사이에 확립된다.

SLCM과 함께, ACM 및 UNCM 기능들은 애플리케이션들이 E2E 도달가능성 스케줄들, E2E 레이턴시, 및 E2E 처리율과 같은 애플리케이션 특정 QoS 요건들이 정의될 수 있는 E2E SL 세션을 서로 확립하게 한다. SLCM, ACM, 및 UNCM 기능들의 지원을 통해, SL들은 기반 오픈플로우 가능한 스위치들 /라우터들과 뿐만 아니라 서로 조정할 수 있다. 이 조정을 통해, 도달가능성 스케줄들, 레이턴시, 및 처리율의 적절한 조정들 및 정렬들이 서비스 계층 및 기반 라우터들 둘 다에서 달성될 수 있다. 그렇게 하는데 있어서, AE들의 E2E QoS 요건들은 본 개시내용에서 포착된 제안된 방법들을 사용하여 홉 바이 홉 기초로 그리고 궁극적으로 E2E 기초로 조정된 SL들에 의해 관리될 수 있다. 결과적으로, 애플리케이션들은 그들의 특정된 E2E QoS 요건들을 충족하는 방식으로 E2E SL 세션을 사용하여 서로 통신할 수 있다.

도 28은 E2E QoS를 구성하기 위해 사용될 수 있는 그래픽 사용자 인터페이스의 예를 도시한다. 도시한 것과 같은 그래픽 사용자 인터페이스는 예로서 표 2에 제공된 것과 같은 선택 용어들을 제공한다. 이 GUI는 본 개시내용에서 정의된 ACM 또는 SLCM 기능들의 본래 특징으로서 지원될 수 있다. 대안적으로, 이 GUI는 ACM 또는 SLCM 기능들이 인터페이스할 수 있는 그 자신의 기능으로서 구현될 수 있다. 이 GUI는 그 자체(또는 그것의 제어 하에 있는 애플리케이션)와 하나 이상의 타깃된 M2M/IoT 디바이스들(또는 이들 디바이스 상에 호스트된 애플리케이션들) 사이에 원하는 레벨의 E2E QoS를 사용자가 구성하게 할 수 있다. GUI는 표 2에 정의된 QoS 파라미터들 중 하나 이상을 지원할 수 있다. GUI는 고, 중, 저와 같은 QoS 파라미터들에 대한 사용자 친화 설정들/옵션들을 지원할 수 있다. GUI 및/또는 ACM 또는 SLCM은 결국 이들 GUI 설정을 기반 네트워크들에 의해 보다 잘 해석되는 보다 상세한 값/특정 QoS 설정들로 변환할 수 있다. 예를 들어, 고, 중, 저 처리율은 각각 >10Mbits/sec, <10Mbits/sec이지만 >1Mbits/sec, 및 <1MBits/sec로 변환될 수 있다. 대안적으로, GUI는 보다 특정한 옵션들 및/또는 값들을 지원할 수 있다.

도 29는 여기에 논의된 방법들 및 시스템들에 기초하여 발생될 수 있는 예시적인 디스플레이(예를 들어, 그래픽 사용자 인터페이스)를 도시한다. 디스플레이 인터페이스(201)(예를 들어, 터치 스크린 디스플레이)는 표 1 내지 표 8의 파라미터들과 같은, 서비스 관리의 서비스 계층 품질과 연관된 블록(202)에서 텍스트를 제공할 수 있다. 또 하나의 예에서, 여기에 논의된 단계들(예를 들어, 송신된 메시지들 또는 단계들의 성공)의 어떤 것의 진행이 블록(202)에 디스플레이될 수 있다. 또한, 그랙픽 출력(203)이 디스플레이 인터페이스(201) 상에 디스플레이될 수 있다. 그래픽 출력(203)은 그들이 다수의 네트워크에 걸침에 따른 디바이스들의 토폴로지, 여기서 논의된 임의의 방법 또는 시스템의 진행의 그래픽 출력 등일 수 있다.

도 30a는 IoT E2E 서비스 계층 QoS 관리와 연관된 하나 이상의 개시된 개념이 구현될 수 있는 예시적인 머신 대 머신(M2M), 사물 인터넷(IoT), 또는 사물 웹(WoT) 통신 시스템(10)의 도면이다. 일반적으로, M2M 기술들은 IoT/WoT에 대한 빌딩 블록들을 제공하고, 임의의 M2M 디바이스, M2M 게이트웨이 또는 M2M 서비스 플랫폼은 IoT/WoT 서비스 계층뿐만 아니라 IoT/WoT의 소자 등일 수 있다.

도 30a에 도시한 바와 같이, M2M/IoT/WoT 통신 시스템(10)은 통신 네트워크(12)를 포함한다. 통신 네트워크(12)는 고정된 네트워크(예를 들어, 이더넷, 파이버, 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 디바이스들(예를 들어, PLC)뿐만 아니라 무선 M2M 디바이스들(예를 들어, 셀룰러 및 비셀룰러)이 통신 네트워크(12)와 같은 운영자 네트워크들 또는 직접 무선 링크를 통해 통신하게 한다. 예를 들어, M2M 디바이스들(18)은 통신 네트워크(12) 또는 직접 무선 링크를 통해 데이터를 수집하고 데이터를 M2M 애플리케이션(20) 또는 M2M 디바이스들(18)에 송신할 수 있다. M2M 디바이스들(18)은 또한 M2M 애플리케이션(20) 또는 M2M 디바이스(18)로부터 데이터를 수신할 수 있다. 또한, 데이터 및 신호들은 아래에 설명되는 바와 같이, M2M 애플리케이션(20)으로부터 M2M 서비스 계층(22)을 통해 송신 및 수신될 수 있다. M2M 디바이스들(18) 및 게이트웨이들(14)은 예를 들어 셀룰러, WLAN, WPAN(예를 들어, 지그비, 6LoWPAN, 블루투스), 직접 무선 링크, 및 유선을 포함하는 다양한 네트워크들을 통해 통신할 수 있다.

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

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

도 30b를 또한 참조하면, M2M 서비스 계층(22 및 22')은 다양한 애플리케이션들 및 버티컬들이 레버리지할 수 있는 서비스 전달 능력들의 코어 세트를 제공한다. 이들 서비스 능력은 M2M 애플리케이션들(20 및 20')이 디바이스들과 상호작용하고 데이터 수집, 데이터 분석, 디바이스 관리, 보안, 빌링 서비스/디바이스 발견 등과 같은 기능들을 수행하게 한다. 본질적으로, 이들 서비스 능력은 이들 기능성을 구현하는 부담에서 애플리케이션들을 자유롭게 하므로, 애플리케이션 개발을 단순화하고 제품의 출시 비용 및 시간을 줄인다. 서비스 계층(22 및 22')은 또한 서비스 계층(22 및 22')이 제공하는 서비스들과 관련하여 다양한 네트워크들(12 및 12')을 통해 M2M 애플리케이션들(20 및 20')이 통신하게 한다.

일부 예들에서, M2M 애플리케이션들(20 및 20')은 여기서 논의된 바와 같이, SL QoS를 사용하여 통신하는 원하는 애플리케이션들을 포함할 수 있다. M2M 애플리케이션들(20 및 20')은 제한 없이, 교통, 건강 및 웰니스, 커넥티드 홈, 에너지 관리, 자산 추적, 및 보안 및 감시와 같은 다양한 산업들에서의 애플리케이션들을 포함할 수 있다. 위에 언급된 바와 같이, 디바이스들, 게이트웨이들, 및 시스템의 다른 서버들에 걸쳐 실행하는 M2M 서비스 계층은 예를 들어, 데이터 수집, 디바이스 관리, 보안, 빌링, 위치 추적/지오펜싱, 디바이스/서비스 발견, 레거시 시스템들 통합과 같은 기능들을 지원하고, M2M 애플리케이션들(20 및 20')에 서비스들로서 이들 기능을 제공한다.

본원의 SL QoS 관리는 서비스 계층의 일부로서 구현될 수 있다. 서비스 계층(예를 들어, IoT SL(166))은 애플리케이션 프로그래밍 인터페이스들(API들) 및 기반 네트워킹 인터페이스들의 세트를 통해 부가 가치 서비스 능력들을 지원하는 소프트웨어 미들웨어 계층이다. M2M 엔티티(예를 들어, 디바이스, 게이트웨이, 또는 하드웨어와 소프트웨어의 조합에 의해 구현될 수 있는 서비스/플랫폼과 같은 M2M 기능적 엔티티)는 애플리케이션 또는 서비스를 제공할 수 있다. ETSI M2M과 oneM2M 둘 다는 본원의 SL QoS 관리를 포함할 수 있는 서비스 계층을 사용한다. ETSI M2M의 서비스 계층은 서비스 능력 계층(SCL)이라고 한다. SCL은 M2M 디바이스(여기서 디바이스 SCL(DSCL)이라고 함), 게이트웨이(여기서 게이트웨이 SCL(GSCL)이라고 함) 및/또는 네트워크 노드(여기서 네트워크 SCL(NSCL)이라고 함) 내에서 구현될 수 있다. oneM2M 서비스 계층은 공통 서비스 기능들(CSF들)(예를 들어, 서비스 능력들)의 세트를 지원한다. 하나 이상의 특정한 유형의 CSF들의 세트의 인스턴스화는 상이한 유형들의 네트워크 노드들(예를 들어, 인프라스트럭처 노드, 미들 노드, 애플리케이션-특정 노드) 상에 호스트될 수 있는 공통 서비스 엔티티(CSE)라고 한다. 또한, 본원의 SL QoS 관리는 본원의 SL QoS 관리와 같은 서비스들에 액세스하기 위해 서비스 지향 아키텍처(SOA) 및/또는 리소스 지향 아키텍처(ROA)를 사용하는 M2M 네트워크의 일부로서 구현될 수 있다.

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

도 30c는 예를 들어, M2M 단말 디바이스(18)(예를 들어, IoT 디바이스(153)) 또는 M2M 게이트웨이 디바이스(14)(예를 들어, IoT 게이트웨이(152))와 같은 예시적인 M2M 디바이스(30)의 시스템도이다. 도 30c에 도시한 바와 같이, M2M 디바이스(30)는 프로세서(32), 송수신기(34), 송신/수신 요소(36), 스피커/마이크로폰(38), 키패드(40), 디스플레이/터치패드(42), 비이동식 메모리(44), 이동식 메모리(46), 전원(48), 전지구 위치파악 시스템(GPS) 칩셋(50), 및 다른 주변 장치들(52)을 포함할 수 있다. M2M 디바이스(30)는 개시된 주제와 일치하게 남으면서 전술한 요소들의 임의의 부조합을 포함할 수 있다는 것을 알 것이다. M2M 디바이스(30)(예를 들어, IoT 디바이스(130), IoT 게이트웨이(152), IoT 서버(151), IoT 디바이스(154) 등)는 SL QoS 관리를 위해 개시된 시스템들 및 방법들을 수행하는 예시적인 구현일 수 있다.

프로세서(32)는 범용 프로세서, 특수 목적 프로세서, 통상적인 프로세서, 디지털 신호 프로세서(DSP), 복수의 마이크로프로세서들, DSP 코어와 관련한 하나 이상의 마이크로프로세서, 컨트롤러, 마이크로컨트롤러, 주문형 집적 회로들(ASIC들), 필드 프로그래머블 게이트 어레이(FPGA들) 회로들, 기타 유형들의 집적 회로(IC), 상태 머신 등일 수 있다. 프로세서(32)는 신호 코딩, 데이터 처리, 전력 제어, 입/출력 처리, 및/또는 M2M 디바이스(30)가 무선 환경에서 동작하게 하는 기타 기능성을 수행할 수 있다. 프로세서(32)는 송신/수신 요소(36)에 결합될 수 있는, 송수신기(34)에 결합될 수 있다. 도 30c가 프로세서(32)와 송수신기(34)를 별개의 소자들로서 도시하지만, 프로세서(32)와 송수신기(34)는 전자 패키지 또는 칩 내에 함께 통합될 수 있다는 것을 알 것이다. 프로세서(32)는 애플리케이션-계층 프로그램들(예를 들어, 브라우저들) 및/또는 무선 액세스-계층(RAN) 프로그램들 및/또는 통신들을 수행할 수 있다. 프로세서(32)는 인증, 보안 키 동의와 같은 보안 동작들, 및/또는 예를 들어 액세스-계층 및/또는 애플리케이션 계층과 같은 암호화 동작들을 수행할 수 있다.

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

또한, 송신/수신 요소(36)가 도 30c에 단일 요소로서 도시되지만, M2M 디바이스(30)는 임의 수의 송신/수신 요소들(36)을 포함할 수 있다. 보다 구체적으로, M2M 디바이스(30)는 MIMO 기술을 이용할 수 있다. 그러므로, 한 예에서, M2M 디바이스(30)는 무선 신호들을 송신 및 수신하기 위한 2개 이상의 송신/수신 요소들(36)(예를 들어, 다중 안테나들)을 포함할 수 있다.

송수신기(34)는 송신/수신 요소(36)에 의해 송신될 신호들을 변조하고 송신/수신 요소(36)에 의해 수신된 신호들을 복조하도록 구성될 수 있다. 위에 주목된 바와 같이, M2M 디바이스(30)는 다수-모드 능력들을 가질 수 있다. 그러므로, 송수신기(34)는 M2M 디바이스(30)가 예를 들어, UTRA 및 IEEE 802.11과 같은 다중 RAT들을 통해 통신하게 하는 다수의 송수신기들을 포함할 수 있다.

프로세서(32)는 비이동식 메모리(44) 및/또는 이동식 메모리(46)와 같은, 임의 유형의 적합한 메모리로부터의 정보에 액세스하고, 그 안에 데이터를 저장할 수 있다. 비이동식 메모리(44)는 랜덤 액세스 메모리(RAM), 리드 온리 메모리(ROM), 하드 디스크, 또는 기타 유형의 메모리 저장 디바이스를 포함할 수 있다. 이동식 메모리(46)는 가입자 식별 모듈(SIM) 카드, 메모리 스틱, 시큐어 디지털(SD) 메모리 카드 등을 포함할 수 있다. 다른 예들에서, 프로세서(32)는 서버 또는 홈 컴퓨터 상에 있는 것과 같이, M2M 디바이스(30) 상에 물리적으로 배치되지 않는 메모리로부터의 정보에 액세스하고, 그 안에 데이터를 저장할 수 있다. 프로세서(32)는 여기에 설명된 예들 중 일부에서의 LMS가 성공적인지 성공적이 아닌지에(예를 들어, SL QoS 요구 또는 응답)에 따라 디스플레이 또는 표시기들(42) 상의 조명 패턴들, 영상들, 또는 색들을 제어하고, 또는 그렇지 않으면 SL QoS 관리 및 연관된 소자들의 상태를 표시하도록 구성될 수 있다. 디스플레이 또는 표시기들(42) 상의 제어 조명 패턴들, 영상들, 또는 색들은 도시되고 또는 여기에 논의된 도면(예를 들어, 도 9 - 도 29 등) 내의 방법 흐름들 또는 소자들의 임의의 것의 상태를 반영할 수 있다. SL QoS 관리를 위한 리소스뿐만 아니라 SL QoS 관리의 메시지들 및 절차들이 여기에 개시된다. 메시지들 및 절차들은 사용자들이 입력 소스(예를 들어, 스피커/마이크로폰(38), 키패드(40), 또는 디스플레이/터치패드(42))를 통해 리소스-관련 리소스들을 요구하고 무엇보다도, 디스플레이(42) 상에 디스플레이될 수 있는 리소스들의 SL QoS를 요구, 구성, 또는 질의하는 인터페이스/API를 제공하도록 확장될 수 있다.

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

프로세서(32)는 또한 M2M 디바이스(30)의 현재 위치에 관한 위치 정보(예를 들어, 경도 및 위도)를 제공하도록 구성된 GPS 칩셋(50)에 결합될 수 있다. M2M 디바이스(30)는 여기에 개시된 정보와 일치하게 남으면서 임의의 적합한 위치-결정 방법에 의해 위치 정보를 취득할 수 있다.

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

송신/수신 요소들(36)은 센서, 소비자 전자 장치들과 같은 다른 장치들 또는 디바이스들, 스마트 워치 또는 스마트 의복과 같은 웨어러블 디바이스, 의료 또는 e헬스 디바이스, 로봇, 산업용 장비, 드론, 차, 트럭, 기차, 또는 항공기와 같은 차량에서 실시될 수 있다. 송신/수신 요소들(36)은 주변 장치들(52) 중 하나를 포함할 수 있는, 상호접속 인터페이스와 같은 하나 이상의 상호접속 인터페이스를 통해 다른 소자들, 모듈들, 또는 이러한 장치들 또는 디바이스들의 시스템들과 접속할 수 있다.

도 30d는 예를 들어, 도 30a 및 도 30b의 M2M 서비스 플랫폼(22)이 구현될 수 있는, 예시적인 컴퓨팅 시스템(90)의 블록도이다. 컴퓨팅 시스템(90)(예를 들어, M2M 단말 디바이스(18) 또는 M2M 게이트웨이 디바이스(14))는 컴퓨터 또는 서버를 포함할 수 있고 소프트웨어의 형태, 이러한 소프트웨어가 어디에 저장되거나 액세스되든지, 또는 어떤 수단이든지 간에 주로 컴퓨터 판독가능 명령어들에 의해 제어될 수 있다. 이러한 컴퓨터 판독가능 명령어들은 컴퓨팅 시스템(90)으로 하여금 동작하게 하게 위해 중앙 처리 장치(CPU)(91) 내에서 실행될 수 있다. 많은 공지된 워크스테이션들, 서버들, 및 개인용 컴퓨터들에서, 중앙 처리 장치(91)는 마이크로프로세서라고 하는 단일-칩 CPU에 의해 구현된다. 다른 머신들에서, 중앙 처리 장치(91)는 다중 프로세서들을 포함할 수 있다. 코프로세서(81)는 추가의 기능들을 수행하거나 CPU(91)를 지원하는 메인 CPU(91)와 분리된, 선택적 프로세서이다. CPU(91) 및/또는 코프로세서(81)는 SL QoS 요구들 또는 응답들을 수신하는 것과 같은, SL QoS 관리를 위한 개시된 시스템들 및 방법들에 관련된 데이터를 수신, 발생, 및 처리할 수 있다.

동작 시에, 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)은 컴퓨팅 시스템(90)을 도 30a 및 도 30b의 네트워크(12)와 같은, 외부 통신 인터페이스에 접속하기 위해 사용될 수 있는 네트워크 어댑터(97)를 포함할 수 있다.

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

도면에 도시된 것과 같은 - 본 개시내용의 주제 - IoT E2E SL QoS 관리의 양호한 방법들, 시스템들, 또는 장치들을 설명하는데 있어서, 특정한 용어가 명료성을 위해 사용된다. 예를 들어, 요구된 용어(예를 들어, 표 2)는 필요조건이 아니라 단지 선호를 위해 사용될 수 있다. 그러나, 청구된 주제는 그렇게 선택된 특정한 용어로 제한되는 것으로 의도되지 않고, 각각의 특정한 요소는 유사한 목적을 달성하기 위해 유사한 방식으로 동작하는 모든 기술적 등가물을 포함한다는 것을 이해할 것이다.

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

본 명세서는 최상의 모드를 포함하는 예들을 사용하여 본 발명을 개시하고, 또한 본 기술 분야의 통상의 기술자가 임의의 디바이스들 또는 시스템들을 만들고 사용하고 임의의 포함된 방법들을 수행하는 것을 포함하는, 발명을 실시하게 한다. 본 발명의 특허가능한 범위가 청구범위에 의해 정의되고 본 기술 분야의 통상의 기술자들에게 분명한 (예를 들어, 여기에 개시된 예시적인 방법들 사이에서 단계들을 건너뛰고, 단계들을 조합하고, 단계들을 추가하는) 다른 예들을 포함할 수 있다. 이러한 다른 예들은 그들이 청구범위의 문자 그대로의 언어와 상이하지 않는 구조적 요소들을 갖거나, 그들이 청구범위의 문자 그대로의 언어들과 많지 않은 차이들을 갖는 등가적인 구조적 요소들을 포함한다면 청구범위의 범위 내에 드는 것으로 간주된다.

무엇보다도, 여기에 설명된 것과 같은, 방법들, 시스템들, 및 장치들은 IoT E2E SL QoS 관리를 위한 수단을 제공할 수 있다. 방법, 시스템, 컴퓨터 판독가능 저장 매체, 또는 장치는 애플리케이션에 대한 단-대-단 서비스 품질 요건들을 결정하고; 확립될 단-대-단 서비스 계층 세션에 대한 요구를 전송하고 - 요구는 애플리케이션에 대한 결정된 단-대-단 서비스 품질 요건들을 포함함 -; 원격 장치와의 단-대-단 서비스 계층 세션의 확립을 확인하는 메시지를 수신하고; 원격 장치와의 단-대-단 서비스 계층 세션의 확립을 확인하는 메시지를 수신한 것에 응답하여, 단-대-단 서비스 계층 세션을 사용하여 통신하는 수단을 갖는다. 메시지는 확립된 단-대-단 서비스 계층 세션에 대한 서비스 계층 식별을 포함할 수 있다. 애플리케이션은 기반 네트워크를 구성하는 서비스 계층에 서비스 품질 요건을 제공할 수 있고, 기반 네트워크는 장치들과 다른 서비스 계층 장치를 접속한다. 애플리케이션은 요구를 통해 서비스 계층에 서비스 품질 요건을 제공할 수 있고, 서비스 계층은 기반 네트워크를 구성하고, 기반 네트워크는 장치와 다른 서비스 계층 장치를 접속한다. 서비스 품질 요건은 단-대-단 서비스 계층 세션에 대한 최소 처리율 임계를 포함할 수 있다. 서비스 품질 요건은 단-대-단 서비스 계층 세션에 대한 최소 도달가능성 스케줄 또는 단-대-단 서비스 계층 세션에 대한 최소 지터 임계를 포함할 수 있다. 서비스 품질 요건은 단-대-단 서비스 계층 세션에 대한 최소 에러율 임계 또는 단-대-단 서비스 계층 세션에 대한 최소 레이턴시 임계를 포함할 수 있다. 서비스 품질 요건은 단-대-단 서비스 계층 세션에 대한 최소 보안 레벨 임계를 포함할 수 있다. (단계들의 제거 또는 추가를 포함하는) 본 단락에서의 모든 조합들은 상세한 설명의 다른 부분들과 일치하는 방식으로 고려된다.

Claims (20)

1. 다수의 기반 네트워크 기술들(underlying network technologies)을 가로질러 걸친 멀티-홉 통신 경로에 대한 단-대-단(end-to-end) 서비스 품질을 관리하기 위한 장치로서, 상기 장치는:
   프로세서; 및
   상기 프로세서에 결합되고, 상기 프로세서에 의해 실행될 때 상기 프로세서로 하여금 동작들을 실행하게 하는 실행가능한 명령어들을 포함하는 메모리
   를 포함하고, 상기 동작들은:
   애플리케이션에 대한 단-대-단 서비스 품질 요건들을 결정하는 동작;
   복수의 상기 기반 네트워크 기술들 중 하나 이상이 상기 결정된 단-대-단 서비스 품질 요건들을 지원할 수 있는지 여부를 결정하는 동작;
   복수의 상기 기반 네트워크 기술들 중 하나 이상이 상기 결정된 단-대-단 서비스 품질 요건들을 지원할 수 있는지 여부에 기초하여, 상기 멀티-홉 통신 경로에서 다음 홉을 제공하기 위해, 상기 기반 네트워크 기술들 중 하나를 선택하는 동작;
   상기 선택된 기반 네트워크 기술을 통해, 확립될 단-대-단 서비스 계층 세션에 대한 요구를 전달하는 동작 - 상기 요구는 상기 애플리케이션에 대한 상기 결정된 단-대-단 서비스 품질 요건들을 포함하고, 상기 애플리케이션은 상기 다수의 기반 네트워크 기술들을 구성하는 서비스 계층에 상기 서비스 품질 요건들을 제공하고, 상기 다수의 기반 네트워크 기술들은 상기 장치와 또 하나의 서비스 계층 장치를 접속함 -;
   원격 장치와의 상기 단-대-단 서비스 계층 세션의 확립을 확인하는 메시지를 수신하는 동작; 및
   상기 원격 장치와의 단-대-단 서비스 계층 세션의 확립을 확인하는 메시지를 수신한 것에 응답하여, 상기 단-대-단 서비스 계층 세션을 사용하여 통신하는 동작
   을 포함하는 장치.
2. 제1항에 있어서, 상기 메시지는 상기 확립된 단-대-단 서비스 계층 세션에 대한 서비스 계층 식별을 포함하는 장치.
3. 제1항에 있어서, 상기 애플리케이션은 상기 서비스 품질 요건들을 상기 요구를 통해 서비스 계층에 제공하고, 상기 서비스 계층은 기반 네트워크를 구성하고, 상기 기반 네트워크는 상기 장치와 또 하나의 서비스 계층 장치를 접속하는 장치.
4. 제1항에 있어서, 상기 서비스 품질 요건들은 상기 단-대-단 서비스 계층 세션에 대한 최소 처리율 임계(minimum throughput threshold)를 포함하는 장치.
5. 제1항에 있어서, 상기 서비스 품질 요건들은 상기 단-대-단 서비스 계층 세션에 대한 최소 도달가능성 스케줄을 포함하는 장치.
6. 제1항에 있어서, 상기 서비스 품질 요건들은 상기 단-대-단 서비스 계층 세션에 대한 최소 에러율 임계를 포함하는 장치.
7. 제1항에 있어서, 상기 서비스 품질 요건들은 상기 단-대-단 서비스 계층 세션에 대한 최소 보안 레벨 임계를 포함하는 장치.
8. 다수의 기반 네트워크 기술들을 가로질러 걸친 멀티-홉 통신 경로에 대한 단-대-단 서비스 품질을 장치에 의해 관리하기 위한 방법으로서, 상기 방법은:
   애플리케이션에 대한 단-대-단 서비스 품질 요건들을 결정하는 단계;
   복수의 상기 기반 네트워크 기술들 중 하나 이상이 상기 결정된 단-대-단 서비스 품질 요건들을 지원할 수 있는지 여부를 결정하는 단계;
   복수의 상기 기반 네트워크 기술들 중 하나 이상이 상기 결정된 단-대-단 서비스 품질 요건들을 지원할 수 있는지 여부에 기초하여, 상기 멀티-홉 통신 경로에서 다음 홉을 제공하기 위해, 상기 기반 네트워크 기술들 중 하나를 선택하는 단계;
   상기 선택된 기반 네트워크 기술을 통해, 확립될 단-대-단 서비스 계층 세션에 대한 요구를 전달하는 단계 - 상기 요구는 상기 애플리케이션에 대한 상기 결정된 단-대-단 서비스 품질 요건들을 포함하고, 상기 애플리케이션은 상기 다수의 기반 네트워크 기술들을 구성하는 서비스 계층에 상기 서비스 품질 요건들을 제공하고, 상기 다수의 기반 네트워크 기술들은 상기 장치와 원격 장치를 접속함 -;
   상기 장치와 원격 장치 간의 상기 단-대-단 서비스 계층 세션의 확립을 확인하는 메시지를 수신하는 단계; 및
   상기 원격 장치와의 단-대-단 서비스 계층 세션의 확립을 확인하는 메시지를 수신한 것에 응답하여, 상기 단-대-단 서비스 계층 세션을 사용하여 통신하는 단계
   를 포함하는 방법.
9. 제8항에 있어서, 상기 메시지는 상기 확립된 단-대-단 서비스 계층 세션에 대한 서비스 계층 식별을 포함하는 방법.
10. 제8항에 있어서, 상기 서비스 품질 요건들은 상기 단-대-단 서비스 계층 세션에 대한 최소 레이턴시 임계를 포함하는 방법.
11. 제8항에 있어서, 상기 서비스 품질 요건들은 상기 단-대-단 서비스 계층 세션에 대한 최소 지터 임계를 포함하는 방법.
12. 제8항에 있어서, 상기 서비스 품질 요건들은 상기 단-대-단 서비스 계층 세션에 대한 최소 도달가능성 스케줄을 포함하는 방법.
13. 제8항에 있어서, 상기 서비스 품질 요건들은 상기 단-대-단 서비스 계층 세션에 대한 최소 에러율 임계를 포함하는 방법.
14. 제8항에 있어서, 상기 서비스 품질 요건들은 상기 단-대-단 서비스 계층 세션에 대한 최소 보안 레벨 임계를 포함하는 방법.
15. 컴퓨터 프로그램이 저장되어 있는 컴퓨터 판독가능 저장 매체로서,
    상기 컴퓨터 프로그램은 데이터 처리 유닛 내로 로드가능하고 상기 데이터 처리 유닛으로 하여금 상기 컴퓨터 프로그램이 상기 데이터 처리 유닛에 의해 실행될 때 제8항 내지 제14항 중 어느 한 항에 따른 방법 단계들을 실행하게 하도록 적응된 컴퓨터 판독가능 저장 매체.
16. 삭제
17. 삭제
18. 삭제
19. 삭제
20. 삭제

Images