KR102409214B1 - 사용자 장비를 위한 이동 코어 네트워크 서비스 노출 - Google Patents

Abstract

서비스 능력 노출 기능이 UE(U-SCEF)에 추가될 수 있다. U-SCEF는 UE의 운영 체체(OS)의 일부이고 API를 이들 애플리케이션이 주기적 센서 측정들 또는 펌웨어 다운로드와 같은 데이터 평면 통신을 스케줄하게 하는 애플리케이션들에 노출시킬 수 있다. U-SCEF는 이동 네트워크 운영자의 (S)Gi-LAN 내에 상주하는 EPC 인터워킹 서비스와 통신한다. EPC 인터워킹 서비스는 SCEF를 통해 MNO에 의해 노출된 U-SCEF와 서비스 능력들 간의 인터페이스의 역할을 한다. U-SCEF는 EPC 인터워킹 서비스에 UE의 예상된 통신 스케줄 및 이동성 상태에 관한 정보를 제공할 수 있다. EPC 인터워킹 서비스는 UE들이 통신하는 최적 시간들, 최적 이동성 관리 구성 등을 결정하기 위해 SCEF에 의해 노출된 서비스들을 사용한다. EPC 인터워킹 서비스는 UE(U-SCEF)를 대신하여 EPC(SCEF)와 통신 스케줄을 협상하고 UE 및 이동 네트워크의 필요들에 맞도록 U-SCEF에 통신 정책 또는 이동성 관리 정책을 제공한다.

Description

사용자 장비를 위한 이동 코어 네트워크 서비스 노출 {MOBILE CORE NETWORK SERVICE EXPOSURE FOR THE USER EQUIPMENT}

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

본원은 기술된 바와 같이 그 전체가 본원에 참조로 포함된, 2015년 8월 3일자 출원된 미국 가 특허 출원 번호 제62/200,305호를 우선권 주장한다.

3세대 파트너쉽 프로젝트(3GPP)는 원거리통신 협회들의 그룹들 간의 협력이고 무선, 코어 네트워크 및 서비스 아키텍처를 포함한다. 3GPP는 참조 3GPP TS 23.682, "패킷 데이터 네트워크들 및 애플리케이션들과의 통신을 가능하게 하는 아키텍처 향상들"에서 서비스 능력 노출 기능(SCEF)을 정의한다. 도 1은 이 참조로부터 복사된 것이고 SCEF(102)의 아키텍처를 도시한다.

서비스 능력 노출 기능(SCEF)(102)은 3GPP 네트워크 인터페이스들에 의해 제공된 서비스들 및 능력들을 안전하게 노출하는 수단을 제공한다. SCEF(102)는 노출된 서비스 능력들의 발견을 위한 수단을 제공한다. SCEF(102)는 오픈 모바일 얼라이언스(OMA), 그룹 스페셜 모바일 협회(GSMA), 및 가능하게는 다른 시그널링 스테이션 단체들에 의해 정의된 동종 네트워크 애플리케이션 프로그래밍 인터페이스들(예를 들어, 네트워크 API)을 통해 네트워크 능력들에 액세스를 제공한다. SCEF(102)는 기반 3GPP 네트워크 인터페이스들 및 프로토콜들로부터 서비스들을 추출한다. SCEF(102)의 개별적인 인스턴스들은 서비스 능력들이 노출되는 것 및 애플리케이션 프로토콜 인터페이스(API) 특징들이 지원되는 것에 따라 변화할 수 있다. SCEF(102)는 항상 신뢰 도메인 내에 있다. 애플리케이션은 신뢰 도메인에 속할 수 있거나 신뢰 도메인 밖에 놓일 수 있다.

참조 S2-151426, "배경 데이터 전달을 위한 해결책 업데이트, Huawei, HiSilicon, NTT Docomo, 2015년 4월 13일-17일"은 애플리케이션 서버/서비스 능력 서버(AS/SCS)가 네트워크와 배경 데이터 전달을 스케줄하게 하는 3GPP의 해결책을 설명한다. 이 참조에서 설명된 방식은 AS/SCS가 정책 및 과금 규칙들 기능(PCRF)(104)과의 데이터 전달을 스케줄하게 한다. PCRF(104)는 데이터 전달을 언제 시작할지를 AS/SCS에 알릴 수 있다. 도 2의 다음의 설명은 참조 S2-151426으로부터 채택된다.

이 방식에서, 이 지리적 영역을 서비스하는 네트워크 내의 가용한 PCRF(104)의 어떤 것은 비로밍 사용자 장비(UE)를 위한 배경 데이터 전달을 위한 전달 정책에 관해 결정을 할 수 있다.

이 방식에서 배경 데이터 전달에 타깃된 UE들은 단일 PCRF(104)에 의해 서비스될 수 있거나 동일한 또는 상이한 지리적 영역들을 서비스하는 다수의 PCRF들에 걸쳐 분산될 수 있다.

전달 정책은 최종적으로 요구의 트랜잭션 참조 허가 승인과 함께 가입 프로필 리포지토리(SPR)(204) 내에 저장된다. 이것은 전달 정책이 미래에 이 배경 데이터 전달의 대상인 UE를 담당하는 모든 PCRF에 가용하게 되는 것을 보장한다. 또한, 다른(또는 동일한) PCRF는 다른 AS에 관련된 배경 데이터에 대한 전달 정책들에 관한 후속 결정들 동안 이 전달 정책을 고려할 수 있다.

AS(202)가 나중 시점에 (기존의 Rx 인터페이스를 통해) 개별적인 UE를 위한 PCRF(104)에 접촉할 때 AS(202)는 또한 참조를 제공할 필요가 있다. 참조는 정책 및 과금 규칙들 기능(PCRF)(104)이 (UE와 관련된) AS(202) 요구를 (AS와 관련된) SPR(204)로부터 검색된 전달 정책과 상관시키게 한다. PCRF(104)는 최종적으로 각각의 정책 및 과금 정보를 정책 및 과금 집행 기능(PCEF)(206)에 제공하기 위해 3GPP TS 23.203에 따라 정책 및 과금 제어(PCC) 절차들을 트리거한다.

AS(202)는 전형적으로 배경 데이터 전달에 대한 스폰서된 접속을 요구하기 위해 개별적인 UE들에 대한 PCRF(104)와 접촉할 것이다.

도 2의 단계 1에서, 제3자 AS(202)는 UE들의 세트에 대한 배경 데이터 전달의 요구를 SCEF(102)에 송신할 수 있다. 배경 데이터 전달 요구 메시지는 애플리케이션 정보, 트래픽 정보(예를 들어, UE마다 전달될 데이터의 볼륨 및 UE들의 예상된 수), 원하는 시간 윈도우 및 선택적으로, 지리적 영역 정보를 포함한다. 애플리케이션 서버(AS)는 UE들의 아이덴티티와 관한 어떤 정보도 제공하지 않는다.

도 2의 단계 2에서, SCEF(102)는 AS 요구를 허가한다. SCEF(102)는 허가(authorization)가 실패하면 이 점에서 AS(202)에 통지한다.

도 2의 단계 3에서, SCEF(102)는 가용한 PCRF들 중 어느 것을 선택하고 AS에 의해 제공된 파라미터들을 포함하는 배경 데이터 전달 요구를 PCRF(104)에 송신한다. AS(202)가 지리적 영역 정보를 제공하면, SCEF(102)는 지리적 영역을 대응하는 네트워크 영역(예를 들어, 셀 id들의 리스트, TA들/RA들)에 전달한다. 새로운 인터페이스가 이 요구가 주어진 UE의 IP-CAN 세션에 특정되지 않을 때 AS(202)와 PCRF(104) 사이의 정보 교환을 위해 SCEF(102)와 PCRF(104) 사이의 상호작용을 위해 도입된다.

도 2의 단계 4에서, PCRF(104)는 (단계 3에서의 요구와 등가일 수 있는) 모든 기존의 전달 정책들에 대해 SPR(204)에 질의한다.

도 2의 단계 5에서, PCRF(104)는 AS(202)에 의해 제공된 정보 및 다른 정보(예를 들어, 네트워크 정책, 혼잡 레벨(가용한 경우), 요구된 시간 윈도우 및 네트워크 영역의 로드 상태 평가, 기존의 전달 정책들)에 기초하여 AS 데이터 전달에 대한 하나 이상의 추천된 시간 윈도우를 결정한다. 각각의 시간 윈도우에 대해, PCRF(104)는 선택적으로 UE들의 세트에 대한 최대 집합된 비트레이트 및 최대 집합된 비트레이트 아래에 머무는 트래픽에 대한 각각의 시간 윈도우에서 적용가능할 과금율을 할당한다. PCRF(104)로부터 SCEF(102)/AS(202)에 제공된 최대 집합된 비트레이트는 네트워크에서 집행되지 않는다.

도 2의 단계 6에서, PCRF(104)는 데이터 전달에 대한 하나 이상의 추천된 시간 윈도우들 및 선택적으로 각각의 시간 윈도우에 대해 UE들의 세트에 대한 최대 집합된 비트레이트 및 과금율을 포함하는 승인된 허가 및 전달 정책 제의를 식별하는 참조 ID로 SCEF(102)에 응답한다.

도 2의 단계 7에서, SCEF(102)는 참조 ID 및 전달 정책 제의를 제3자 AS에 전송한다. AS는 PCRF(104)와의 미래의 상호작용을 위해 참조 ID를 저장한다.

도 2의 단계들 8-11에서, 전달 정책 제의가 하나보다 많은 시간 윈도우를 포함하면, 제3자 AS는 시간 윈도우들 중 하나를 선택하고 그것에 관해 SCEF(102) 및 PCRF(104)에 알리기 위해 배경 데이터 전달 메시지에 대한 또 하나의 요구를 송신할 것이다.

전달 정책 제의 내에 단지 하나의 시간 윈도우가 있으면, AS(202)는 확인하는 것이 요구되지 않는다.

도 2의 단계 12에서, PCRF(104)는 SPR(204) 내에 참조 ID 및 새로운 전달 정책을 저장한다.

도 2의 단계 4에서, AS(202)가 (기존의 Rx 인터페이스를 통해) 개별적인 UE에 대해 나중 시점에 PCRF(104)와 접촉할 때, AS(202)는 참조 ID를 제공한다. PCRF(104)는 참조 ID를 통해 SPR(204)로부터 검색된 전달 정책과 AS 요구를 상관시킨다. PCRF(104)는 이 UE의 배경 데이터 전달을 위해 PCEF(206)에 각각의 정책 및 과금 정보를 제공하기 위해 3GPP TS 23.203에 따라 PCC 절차들을 최종적으로 트리거한다. AS(202)는 전형적으로 배경 데이터 전달을 위한 스폰서된 접속을 요구하기 위해 개별적인 UE들에 대해 PCRF(104)와 접촉할 것이다.

참조 S2-151237("예측가능한 UE 통신 패턴, Ericsson, NEC, 2015년 4월 13일-17일")은 AS/SCS가 네트워크와의 주기적 통신을 스케줄하게 하는 3GPP의 가장 최근의 해결책을 설명한다. 이 참조에서 설명된 방식은 AS/SCS가 네트워크와의 주기적 데이터 전달을 스케줄하고 네트워크에 그것의 예상된 이동성 패턴을 제공하게 한다. PCRF(104)는 데이터 전달을 언제 시작할지를 AS/SCS에 알릴 수 있다. 도 3의 다음의 설명이 참조 S2-151237로부터 채택된다.

도 3의 해결책은 "예측가능한 통신 패턴들을 위한 정보에 대한 제3자 상호작용의 지원"을 제공한다. 여기에 설명된 해결책은 이러한 UE(들)에 대한 네트워크 리소스 최적화들을 가능하게 하기 위해서 대응하는 코어 네트워크 노드에 UE 또는 UE의 그룹의 통신 패턴의 관련 정보를 제공하는 메커니즘을 정의한다.

SCEF(102)는 데이터 트래픽에 대한 통신 패턴들 및/또는 이동성 패턴을 수신할 수 있다. 이들 통신 패턴들(CP들) 내에 어떤 종류의 파라미터들이 포함될 수 있는지의 예가 아래의 표들에 나타내진다. SCEF(102)는 그들 통신 패턴들로부터 코어 네트워크 노드들에 대한 통신 패턴(CP) 파라미터들을 선택할 수 있을 것이다.

CP 파라미터들의 세트는 표준화될 수 있지만, 모든 CP 파라미터들은 선택적이다.

다음의 가정들이 이 해결책에 대해 이루어진다:

- SCEF(102)는 제3자 서비스 제공자로부터 수신된 통신 패턴에 기초하여 CP 파라미터들을 필터하고 전송한다.

- SCEF(102)는 CP 파라미터들을 선택된 적절한 기능적 엔티티들(예를 들어, MME(304))에 제공하는 홈 가입자 서버(HSS)(302)에 CP 파라미터들을 제공한다.

- CP 파라미터들의 단지 하나의 세트가 한 때 유효한데, 즉 동일한 SCS/AS(202) 또는 별개의 SCS/AS(202)가 새로운 CP 파라미터들을 제공하면, 그것들은 이전에 제공된 어떤 CP 파라미터들을 오버라이드한다.

SCEF(102)는 제3자 서비스 제공자로부터 수신된 개별적인 UE들 또는 UE들의 그룹들의 통신 패턴들에 기초하여 MME(304)에 분배하기 위해 선택된 CP 파라미터들을 HSS(302)에 제공한다. SCEF(102) 및 HSS(302)로부터의 CP 파라미터들을 포함하는 시그널링은 가입자 레벨에 따른다(HSS(302)로부터 MME(304)에도 또한 그렇다).

도 3(S2-151237으로부터의 도 6.5.1.3-1)은 CP 파라미터들의 제공을 위한 시그널링 시퀀스를 도시한다.

제3자 서비스 제공자는 SCEF(102)에 UE 또는 UE들의 그룹에 대한 통신 패턴에 관해 통지한다. SCEF(102)는 추가 정보에 대해 HSS(302)에 질의하고, 운영자 정책 또는 구성에 기초하여 요구를 인증 및 허가하고 다음에 CP 파라미터들을 선택할 수 있다. SCEF(102)는 CP 파라미터들을 네트워크 리소스 최적화를 개시하는 관련 노드(예를 들어, HSS(302)를 통해 MME(304))에 제공한다. SCEF(102)와 AS/SCS 사이의 인터페이스는 3GPP의 범위 밖에 있고 도 3 내의 메시지들은 예시적이다.

UE 요구된 베어러 리소스 수정을 논의한 이 섹션의 내용들은 참조 3GPP TS 23.401("이볼브드 지상 무선 액세스 네트워크(E-UTRAN) 액세스를 위한 일반 패킷 무선 서비스(GPRS) 향상들")의 섹션 5.4.5로부터 채택된다.

E-UTRAN에 대한 UE 요구된 베어러 리소스 수정 절차가 도 4에 도시된다. 절차는 UE가 특정한 QoS 요구와의 하나의 트래픽 흐름 집합을 위한 베어러 리소스들의 수정(예를 들어, 리소스들의 할당 또는 해제)을 요구하게 한다. 대안적으로, 절차는 QoS를 변경하지 않고서, UE가 활성 트래픽 흐름 집합을 위해 사용된 패킷 필터들의 수정을 요구하게 한다. 네트워크에 의해 받아들여지면, 요구는 전용 베어러 활성화 절차, 베어러 수정 절차를 호출하고 또는 전용 베어러는 패킷 데이터 네트워크들(PDN) 게이트웨이(GW) 개시된 베어러 비활성화 절차를 사용하여 비활성화된다. 절차는 UE가 이미 PDN GW(404)와의 PDN 접속을 가질 때 UE에 의해 사용된다. UE는 이전의 절차가 완료되기 전에 후속하는 요구 베어러 리소스 수정 메시지를 송신할 수 있다.

이 절차에서 UE는 절차 트랜잭션 식별자(PTI), 및 EPS 베어러 아이덴티티와 함께, 부분적 트래픽 흐름 템플릿(TFT)인 트래픽 집합 설명(Traffic Aggregate Description)(TAD)을 시그널링한다(TAD 동작이 수정, 삭제 또는 기존의 패킷 필터에의 추가일 때). TAD 동작이 수정 또는 삭제일 때, TAD의 패킷 필터 식별자들은 그 리소스들이 수정되는, 참조된 이볼브드 패킷 시스템(EPS) 베어러의 TFT 패킷 식별자들과 동일하다(TFT 패킷 필터 식별자와 EPS 베어러 식별자의 연쇄가 PDN 접속 내의 유일한 패킷 필터 식별자를 나타낼 때). TAD는 그것이 네트워크로부터 현재의 PTI에 관련된 TFT를 수신한 후에 UE에 의해 해제된다.

도 4의 단계들 1, 2, 및 5는 GPRS 터널링 프로토콜(GTP)-기반 S5/S8 및 프록시 모바일 IPv6(PMIP)-기반 S5/S8을 갖는 아키텍처 변형들에 공통이다. (A)로 표시된 절차 단계들은 PMIP-기반 S5/S8이 TS 23.402에서 이용되고 정의되는 경우에 상이하다.

도 4의 단계 1에서, UE(402)는 MME(304)에 요구 베어러 리소스 수정[링크된 베어러 Id(LBI), 절차 트랜잭션 식별자(PTI), EPS 베어러 아이덴티티, 서비스의 품질(QoS), 트래픽 집합 설명(TAD), 프로토콜 구성 옵션들] 메시지를 송신한다. UE(402)가 ECM-IDLE 모드(ECM이 EPS 접속 관리를 나타내는 경우)에 있었다면, 이 비액세스 스트라텀(NAS) 메시지가 서비스 요구 절차를 뒤따른다.

TAD는 한 요구된 동작(패킷 필터들을 추가, 수정, 또는 삭제하는 것)을 표시한다. 트래픽 흐름들이 추가되면, TAD는 추가될 (패킷 필터 식별자 없이, 패킷 필터 선행을 포함하는 패킷 필터 정보로 이루어진) 패킷 필터(들)를 포함한다. UE(402)는 추가된 트래픽 흐름들에 대해, 적용가능한 경우에, 요구된 QoS 등급 식별자(QCI) 및 보증된 비트 레이트(GBR)를 또한 송신한다. UE(402)가 새로운 패킷 필터에 대한 기존의 베어러 리소스들의 사용을 가능하게 하기 위해 새로운 패킷 필터를 기존의 패킷 필터에 링크하기를 원하면, UE(402)는 새로운 패킷 필터와 함께 기존의 패킷 필터 식별자를 제공한다. UE(402)가 추가로 GBR을 변경하기를 원하면, UE(402)는 EPS 베어러의 GBR 요건을 포함한다. TAD는 절차가 완료될 때 해제된다.

GBR의 수정(즉, 감소 또는 증가)을 요구할 때, TAD는 GBR 변경 요구가 적용하는 패킷 필터 식별자(들)를 포함할 것이다. UE(402)는 EPS 베어러의 GBR 요건을 포함한다. TAD는 절차가 완료될 때 해제된다.

패킷 필터의 수정(예를 들어, 포트 번호의 변경)을 요구할 때, TAD는 변경 요구가 변경된 패킷 필터 정보와 함께 적용하는 패킷 필터 식별자를 포함할 것이다.

UE(402)가 트래픽 흐름들의 삭제를 요구하면, TAD는 삭제될 패킷 필터 식별자(들)를 포함한다. 삭제될 패킷 필터들이 GBR 베어러와 매핑된다면, UE(402)는 EPS 베어러의 새로운 GBR 요건을 포함한다.

UE(402)는 추가 베어러 리소스가 링크되는 PDN 접속이 어떤 것인지를 표시하기 위해, 요구된 동작이 추가될 때만 링크된 베어러 Id(LBI)를 송신한다. EPS 베어러 아이덴티티는 요구된 동작이 수정 또는 삭제일 때만 송신된다. 절차 트랜잭션 Id는 이 절차 동안 UE(402)에 의해 동적으로 할당된다. UE(402)는 이전에 사용된 PTI 값들이 즉시 재사용되지 않는 것을 가능한 한 보장하여야 한다. PTI는 절차가 완료될 때 해제된다. 프로토콜 구성 옵션들은 UE(402)와 PDN 게이트웨이(GW)(404) 사이에 애플리케이션 레벨 파라미터들을 전달하기 위해 사용될 수 있고, MME(304) 및 서빙 GW(406)을 통해 투명하게 송신된다.

도 4의 단계 2에서, MME(304)는 선택된 서빙 GW(406)에 베어러 리소스 명령[국제 이동 가입자 아이덴티티(IMSI), LBI, PTI, EPS 베어러 아이덴티티, QoS, TAD, 프로토콜 구성 옵션들] 메시지를 송신한다. MME(304)는 링크된 베어러 Id를 사용하여 요구를 유효화한다. 동일한 서빙 GW 어드레스가 요구 베어러 리소스 수정 메시지에서 수신된 링크된 베어러 Id에 의해 식별된 EPS 베어러에 관한 한 MME(304)에 의해 사용된다.

도 4의 단계 3에서, 서빙 GW(406)는 PDN GW(404)에 베어러 리소스 명령(IMSI, LBI, PTI, EPS 베어러 아이덴티티, QoS, TAD, 프로토콜 구성 옵션들] 메시지를 송신한다. 서빙 GW는 링크된 베어러 Id에 의해 식별된 EPS 베어러에 관한 한 메시지를 동일한 PDN GW(404)에 송신한다.

도 4의 단계 4에서, PDN GW(404)는 로컬로 구성된 QoS 정책을 적용할 수 있거나, 그것은 가입 정보를 고려할 수 있는, 적절한 PCC 결정을 트리거하기 위해 PCRF(104)와 상호작용할 수 있다. 이것은 PDN GW(404)가 IP-CAN 베어러 시그널링을 요구하는 시점까지, TS 23.203에서 정의된 것과 같은 PCEF-개시된 IP-CAN 세션 수정 절차의 시작에 대응한다. PCRF(104)와 상호작용할 때, PDN GW(404)는 PCRF(104)에 TAD의 내용 및, 적용가능한 경우에, TAD 내에 포함된 패킷 필터 정보와 연관된 GBR 변경(증가 또는 감소)을 제공한다. GBR 변경은 현재의 베어러 QoS 및 UE(402)로부터의 요구된 베어러 QoS로부터 계산되거나, TAD가 추가 동작을 표시하고 EPS 베어러 아이덴티티가 수신되지 않으면 요구된 GBR로 설정된다. TAD가 추가 동작을 표시하는 경우에, 기존의 패킷 필터 식별자가 새로운 패킷 필터와 함께 제공되지 않는다면 요구된 QCI가 PCRF(104)에 또한 제공된다.

TAD 동작이 수정 또는 삭제이면, PDN GW(404)는 수신된 EPS 베어러 아이덴티티에 의해 표시된 EPS 베어러의 수신된 패킷 필터 식별자들에 대응하는 Gx 상에 이전에 할당된 서비스 데이터 흐름(SDF) 필터 식별자(들)를 제공한다.

도 4의 단계 5에서, 요구가 받아들여지면, (3GPP TS 23.401 "이볼브드 지상 무선 액세스 네트워크(E-UTRAN) 액세스를 위한 일반 패킷 무선 서비스(GPRS) 향상들"의 절 5.4.1에 따른) 전용 베어러 활성화 절차, (3GPP TS 23.401의 절 5.4.4.1에 따른) PDN GW 개시된 베어러 비활성화 절차 또는 (3GPP TS 23.401의 절 5.4.2.1 또는 5.4.3에 따른) 전용 베어러 수정 절차들 중 하나가 호출된다. UE(402)에 의해 할당된 PTI는 그것을 UE 요구된 베어러 리소스 수정 절차와 상관시키기 위해 호출된 전용 베어러 활성화 절차, PDN GW 개시된 베어러 비활성화 절차 또는 전용 베어러 수정 절차 내의 파라미터로서 사용된다. 이것은 UE(402)에 새로운 트래픽 흐름 집합을 위해 사용될 어떤 EPS 베어러와의 필요한 링크를 제공한다. PDN GW(404)는 UE(402)에 의해 요구된 QoS 파라미터들을 수정하지 않을 것이다.

PDN GW(404)는 EPS 베어러를 위한 TFT 내로 TAD에 대응하는 패킷 필터(들)를 삽입, 수정 또는 제거한다. 새로운 패킷 필터가 TFT 내로 삽입될 때, PDN GW(404)는 TFT 내에서 유일한 새로운 패킷 필터 식별자를 할당한다. PDN GW(404)는 PCRF(104)로부터 수신된 PCC 규칙 내의 SDF 필터 식별자와 이 EPS 베어러의 TFT의 패킷 필터 식별자 간의 관계를 유지한다. 전용 EPS 베어러에 대한 패킷 필터(들)의 모두가 TFT로부터 제거되었다면, PDN GW는 PDN GW 개시된 베어러 비활성화 절차를 수행한다.

요구된 QoS가 허가되지 않으면(즉, 요구된 QoS가 받아들여질 수 없거나 리소스들이 할당될 수 없을 때) PDN GW(404)는 UE(402)에 전달될, 베어러 리소스 실패 표시(요구가 실패되거나 거절된 이유를 표시하는 원인으로) 메시지를 송신한다.

도 4의 단계 6에서, PDN GW(404)가 단계 4에서 PCRF(104)와 상호작용했다면, PDN GW(404)는 PCC 결정이 집행될 수 있는지 여부를 PCRF(104)에 표시한다. 이것은 TS 23.203에서 정의된 것과 같은 PCEF-개시된 IP-CAN 세션 수정 절차의 완료에 대응하고, IP-CAN 베어러 시그널링의 완료 후에 진행한다.

M2M 통신들에서 서비스 계층(SL)은 M2M 디바이스들과 소비자 애플리케이션들 간의 안전한 단-대-단(end-to-end) 데이터/제어 교환을 지원함으로써 제3자 부가 가치 서비스들 및 애플리케이션들의 전달을 위한 플랫폼들을 가능하게 하고 원격 제공 & 활성화, 인증, 암호화, 접속 셋업, 버퍼링, 동기화, 집합 및 디바이스 관리를 위한 능력들을 제공하는 것을 목적으로 한다. SL은 기반 네트워크들에 인터페이스들을 제공하고 애플리케이션 프로그래밍 인터페이스들(API들)을 통하는 제3자 콘텐트 제공자들을 통해 액세스된 서비스 제공자들(SP)에 의해 소유된 서버들을 사용하여 능력들을 가능하게 한다.

M2M/IoT 서비스 계층은 구체적으로 M2M/IoT 유형 디바이스들 및 애플리케이션들을 위한 부가 가치 서비스들을 제공하는 것을 목표로 한다. ETSI M2M("머신 대 머신 통신(M2M) 기능적 아키텍처", 드래프트 ETSI TS 102 690 1.1.1(2011-10)) 및 oneM2M TS-0001(oneM2M 기능적 아키텍처)와 같은 표준화 단체들은 센서들 및 디바이스 네트워크들을 구체적으로 타깃하는 M2M 서비스 계층들을 개발하고 있다. 디바이스 관리(DM)는 펌웨어 및 소프트웨어 관리, 보안 및 액세스 제어, 디바이스 감시 및 기록 등과 같은 과제들에 대한 해결책들을 제공하기 위해 최상의 SL 플랫폼들에 의해 타깃된 부가 가치 서비스들 중 하나이다.

oneM2M 아키텍처는 상이한 유형들의 네트워크 노드들(예를 들어, 인프라스트럭처 노드, 중간 노드, 애플리케이션-특정 노드) 상에 호스트될 수 있는 공통 서비스 엔티티(CSE)에 기초한다.

(리소스 지향 아키텍처 또는 RoA라고 또한 공지된) oneM2M RESTful 아키텍처 내에서 CSE(502)는 도 6에 도시한 것과 같이, 공통 서비스 기능들(CSF들)의 세트의 인스턴스화를 지원한다. CSF 기능성은 생성, 검색, 업데이트, 및 삭제와 같은 RESTful 방법들을 통해 조작될 수 있는 표현을 갖는 유일하게 어드레스가능한 엔티티들인 리소스들을 통해 구현된다. 이들 리소소는 유니버설 리소스 식별자들(URI들)을 사용하여 어드레스가능하다. 리소스는 리소스에 관한 관련 정보를 저장하는 속성들의 세트를 지원하고 차일드 리소스(들)라고 하는 다른 리소스들에 대한 참조들을 포함할 수 있다. 차일드 리소스는 페어런트 리소스와 견제 관계를 갖고 그 수명이 페어런트의 리소스 수명에 의해 제한된 리소스이다.

oneM2M은 도입된 RoA 아키텍처 외에 서비스 지향 아키텍처(SoA) 방식("서비스 소자 아키텍처" oneM2M-TS-0007, oneM2M 서비스 소자 아키텍처 V-0.6.0)을 사용하는 규격들을 제공한다. SoA 아키텍처 개념은 별도의 소프트웨어 모듈들에 의해 제공되고 서비스들로서 공지된 기능성을 빌딩 블록들로서 고려하는 것에 기초한다. 서비스들은 판매자, 제품 또는 기술에 독립한 특정된 인터페이스들을 통해 애플리케이션들에 제공된다. oneM2M 내의 CSE 502의 SoA 표현이 도 7에 도시된다.

구축 관점으로부터, 도 8은 oneM2M 아키텍처에 의해 지원된 구성들을 도시한다.

다음의 용어들이 본 맥락에서 사용된다:

● 애플리케이션 서비스 노드(ASN):

○ ASN은 하나의 CSE(502)를 포함하고 적어도 하나의 애플리케이션 엔티티(AE)를 포함한다. 예로서, ASN은 M2M 디바이스 내에 상주할 수 있다.

● 애플리케이션 전용 노드(ADN):

○ ADN은 적어도 하나의 AE를 포함하고 CSE(502)를 포함하지 않는다. 예로서, ADN은 제한된 M2M 디바이스 내에 상주할 수 있다.

● 중간 노드(MN):

○ MN은 하나의 CSE(502)를 포함하고 0개 이상의 AE를 포함한다. 예로서, MN은 M2M 게이트웨이 내에 상주할 수 있다.

● 인프라스트럭처 노드(IN):

○ IN은 하나의 CSE(502)를 포함하고 0개의 이상의 AE를 포함하는 노드이다. 정확히 oneM2M 서비스 제공자마다 인프라스트럭처 도메인 내에 하나의 IN이 있다. 예로서, IN은 M2M 서비스 인프라스트럭처 내에 상주할 수 있다.

● 비-oneM2M 노드(NoDN):

○ 비-oneM2M 노드는 oneM2M 엔티티들(AE도 CSE도)을 포함하지 않는 노드이다. 이러한 노드들은 관리를 포함하는, 인터워킹 목적들을 위해 oneM2M 시스템에 부착된 디바이스들을 나타낸다.

서비스 능력 노출 기능이 UE(U-SCEF)에 추가된다. U-SCEF는 UE의 운영 체체(OS)의 일부이고 API를 이들 애플리케이션이 주기적 센서 측정들 또는 펌웨어 다운로드와 같은 데이터 평면 통신을 스케줄하게 하는 애플리케이션들에 노출시킬 수 있다. 대안적으로, U-SCEF는 UE의 OS 상에 놓인 애플리케이션 또는 서비스일 수 있다.

U-SCEF는 이동 네트워크 운영자의 (S)Gi-LAN 내에 상주하는 이볼브드 패킷 코어(EPC) 인터워킹 서비스와 통신한다. EPC 인터워킹 서비스는 SCEF를 통해 이동 네트워크 운영자(MNO)에 의해 노출된 U-SCEF와 서비스 능력들 간의 인터페이스의 역할을 한다. U-SCEF는 EPC 인터워킹 서비스에 UE의 예상된 통신 스케줄 및 이동성 상태에 관한 정보를 제공할 수 있다. EPC 인터워킹 서비스는 UE들이 통신하는 최적 시간들, 최적 이동성 관리 구성 등을 결정하기 위해 SCEF에 의해 노출된 서비스들을 사용할 것이다. U-SCEF는 또한 일반 패킷 무선 서비스(GPRS) 기반 코어 네트워크와 같은 다른 유형들의 코어 네트워크들과 인터워크하는 서비스와 또한 통신할 수 있다는 점에 주목한다.

EPC 인터워킹 서비스는 UE(U-SCEF)를 대신하여 EPC(SCEF)와 통신 스케줄을 협상하고 UE 및 이동 네트워크의 필요들에 맞도록 U-SCEF에 통신 정책 또는 이동성 관리 정책을 제공한다.

절차들은 UE 애플리케이션들이 MNO와 직접 통신 스케줄들 및 이동성 관리 구성들을 협상하게 한다. UE 애플리케이션들이 통신하는 서버들은 MNO와의 인터페이스를 지원하거나 MNO와의 업무 관계를 확립할 필요가 없다. 서버들은 UE와 MNO 간의 협상에 대해 많이 알지 못할 수 있다.

본 요약은 상세한 설명에서 아래에 더 설명되는 간소화된 형태로 개념들의 선택을 도입하기 위해 제공된다. 본 요약은 청구된 주제의 주요 특징들 또는 본질적인 특징들을 확인하려는 것도 아니고, 청구된 주제의 범위를 제한하기 위해 사용하려는 것도 아니다. 또한, 청구된 주제는 본 개시내용의 어떤 부분에서 주목된 임의의 또는 모든 단점들을 해결하는 제한들로 한정되지 않는다.

첨부 도면과 함께 예로서 주어진, 다음의 상세한 설명으로부터 보다 상세한 이해가 될 수 있다.
도 1은 서비스 능력 노출 기능 아키텍처의 도면이다.
도 2는 배경 데이터 전달을 위한 리소스 관리를 위한 일반적인 방식의 도면이다.
도 3은 CP 파라미터들의 제공을 위한 시그널링 시퀀스의 도면이다.
도 4는 UE 요구된 베어러 리소스 수정의 도면이다.
도 5는 oneM2M 기능적 아키텍처의 도면이다.
도 6은 oneM2M에서의 CSE 내의 공통 서비스들 기능들의 ROA 표현의 도면이다.
도 7은 oneM2M에서의 CSE의 SOA 표현의 도면이다.
도 8은 oneM2M 아키텍처에 의해 지원된 구성들의 도면이다.
도 9는 UE 애플리케이션 인터워킹 아키텍처의 도면이다.
도 10은 스케줄된 통신 사용 경우의 도면이다.
도 11은 주기적 통신 사용 경우의 도면이다.
도 12는 이동성 표시들 사용 경우의 도면이다.
도 13은 한 실시예의 그래픽 사용자 인터페이스의 도면이다.
도 14a는 통신 네트워크를 포함하는 M2M/IoT/WoT 통신 시스템의 도면이다.
도 14b는 M2M 애플리케이션, M2M 게이트웨이 디바이스들, 및 M2M 단말 디바이스들 및 통신 네트워크를 위한 서비스들을 제공하는 필드 도메인 내의 예시된 M2M 서비스 계층의 도면이다.
도 14c는 여기서 설명된 네트워크 노드들 중 어느 것을 구현하기 위해 사용될 수 있는 예시적인 디바이스의 도면이다.
도 14d는 여기서 설명된 네트워크 노드들 중 어느 것을 구현하기 위해 사용될 수 있는 컴퓨터 시스템 또는 서버의 블록도이다.
도 15는 가상화된 네트워크 기능 포워딩 그래프(VNF-FG)의 개념을 도시한 도면이다.
도 16은 네트워크 슬라이싱의 개념적 아키텍처를 도시한 도면이다.
도 17은 다수의 네트워크 슬라이스 인스턴스들을 선택하는 데 있어서의 CNSF를 도시한 도면이다.
도 18은 네트워크 기능들의 상호접속을 위한 비로밍 기준 모델을 도시한 도면이다.
도 19는 네트워크 기능들의 상호접속을 위한 로밍 기준 모델을 도시한 도면이다.

때때로 디바이스 특성들은 실행 시간 중에 변화한다. 일부 특성들을 변화시키는 이벤트가 UE(402)에서 발생할 수 있다. 예를 들어, 사용자는 UE의 스케줄, 우선순위 등을 변화시키는 UE 애플리케이션 상의 설정을 변경할 수 있다.

UE(402)는 네트워크에 그것의 동작 특성들에 관해 알리는 능력을 거의 갖지 않는다. 그러므로, 네트워크는 일부 디바이스들이 고정인 것으로 알려지고, 알려진 시간들에서 통신하다는 사실 등을 항상 이용할 수 없다. 한가지 예외는 디바이스가 낮은 우선순위라는 것을 표시하기 위해 NAS 메시지가 사용될 수 있는 것이다. 또 하나의 예외는 RRC 메시지가 낮은 전력 선호 표시자를 전달하기 위해 사용될 수 있다는 것이다. 그러나, 3GPP 제어 메시지들 내에 통신 스케줄, 예상된 이동성(또는 그것의 부족), 배터리 레벨들 등과 같은 정보를 모두 전달하는 것은 합리적이지 않다.

릴리스 13에서, 3GPP는 SCS와 EPC 사이에 (SCEF(102)를 통해) 인터워킹 능력들을 추가하는 것에 관해 연구한다. 서비스들, 기능들, 또는 노드들이 노출되는 이 유형의 인터워킹은 또한 서비스 노출이라고 할 수 있다. 인터워킹 특징들 중 일부는 SCS가 EPC에 UE의 동작 특성들에 관해 알리게 할 것이다. 그러나, 이들 특징은 MNO와의 업무 관계를 갖는 SCS에 대해서만 인에이블된다. 그러므로, 그것이 MNO와 업무 관계를 갖는 SCS와 페어되지 않으면, UE(402)는 그것의 스케줄, 예상된 이동성(또는 그것의 부족), 배터리 레벨들 등을 알 수 있지만, EPC에 정보를 전달하는 방식을 갖지 않는다. 많은 수들의 디바이스들이 MNO와 업무 관계를 갖지 않는 M2M 서버들과 통신할 것으로 예상된다. 그러므로, 이들 유형들의 디바이스들은 네트워크를 보다 자주 리슨하고, 네트워크가 상대적으로 혼잡할 때 언제나 송신하고, 또는 필요한 것보다 자주 이동성 관리 절차들을 수행하는 것이 강요될 수 있다.

도 9는 UE(402) 플랫폼이 EPC(908)와 인터워크하게 하는 아키텍처를 도시한다. 황색 블록들은 MNO와 업무 관계를 갖지 않을 수 있는 애플리케이션을 나타낸다. 주황색 블록들은 본 개시내용의 초점이고 디바이스 애플리케이션들이 EPC(908)와 인터워크하게 하기 위해 필요한 논리를 나타낸다.

UE 서비스 능력 노출 기능(U-SCEF)(1002)이 UE 플랫폼에 추가될 수 있다. UE 플랫폼은 3GPP 모뎀(L1, L2, 및 L3), 운영 체체, 및 애플리케이션들을 포함할 수 있다.

U-SCEF(902)는 UE의 OS의 일부일 수 있다. 대안적으로, 그것은 UE의 OS의 상부 상에서 실행하는 애플리케이션 또는 서비스일 수 있다. 예를 들어, 그것은 oneM2M AE 또는 oneM2M CSF일 수 있다.

U-SCEF(902)는 UE(402) 애플리케이션들에 노스바운드 API(N-API)를 노출시킬 수 있다. UE 애플리케이션들의 예들은 펌웨어 관리 애플리케이션들, 멀티미디어 애플리케이션들, 차량 진단 애플리케이션들, 센서 측정들을 수집하는 애플리케이션들, 패키지들 또는 물품 목록의 상태를 추적하는 애플리케이션들, 서비스 계층들(즉, oneM2M ASN-CSE 또는 MN-SCE) 등이다.

U-SCEF(902)는 EPC 인터워킹 서비스에 접속하기 위해 PDN 접속을 사용할 수 있다. EPC 인터워킹 서비스는 MNO에 의해 소유되고 신뢰 도메인 내에 있는 것으로 예상된다. EPC 인터워킹 서비스는 oneM2M 공통 서비스 엔티티(CSE), CSE(502) 내의 서비스, 또는 애플리케이션일 수 있다.

U-SCEF(902)와 EPC 인터워킹 서비스(1002)는 S-API(906)를 통해 통신할 수 있다.

EPC 인터워킹 서비스(1002)는 S-API(906)로부터 UE 정보를 획득하고 그것을 SCEF(102)를 통해 EPC(908)에 통과시킨다.

U-SCEF(902)는 또한 그것이 UE의 모뎀을 구성하게 할 수 있는 API에 액세스할 수 있다. 예를 들어, U-SCEF(902)는 애플리케이션들로부터의 입력에 기초하여 모뎀의 이동성 관리 타이머들을 구성할 수 있다.

U-SCEF(902)는 3GPP UE(402) 상에서 실행하는 논리적 기능이다. 그것은 UE 애플리케이션들과 OS 사이에 놓인 모뎀 OS 또는 미들웨어의 일부일 수 있다.

기동 시에, U-SCEF(902)는 통신하기 위해 UE의 디폴트 PDN 접속을 사용할 수 있다. 대안적으로, 사용자는 GUI, API 명령, 어텐션(AT) 명령과 같은 사용자 인터페이스를 통해 U-SCEF 액세스 포인트 명(APN)을 입력할 수 있거나, UE의 가입자 식별 모듈(SIM) 카드 내에 U-SCEF APN을 저장할 수 있다. U-SCEF APN은 네트워크 접속을 확립하기 위해 U-SCEF(902)에 의해 사용될 수 있다. U-SCEF APN은 PDN 접속의 목적이 EPC 인터워킹 서비스(1002)에 접촉한다는 EPC에의 표시의 역할을 할 수 있다. PDN 접속이 확립될 때, MME(304)는 UE(402)가 이 U-SCEF APN에 접속하는 것이 허가된다는 것을 UE의 가입 정보가 표시한다는 것을 체크할 수 있다. U-SCEF의 접속을 위해 특별한 APN을 사용하고 UE 가입 정보를 통해 그것을 허가하는 것은 EPC가 허가되지 않은 UE가 EPC 인터워킹 서비스에 액세스하는 것을 방지하는 편리한 방법을 제공한다.

HSS(302) 내의 UE의 가입 정보는 U-SCEF(902)를 실행하는 것이 허용된다는 것을 표시할 수 있다. 이 표시는 UE(402)가 EPC 인터워킹 서비스에 액세스하기 위해 U-SCEF에 의해 사용되는 특별한 APN에 액세스하는 것이 허용된다는 것일 수 있다.

U-SCEF(902)는 UE(402) 상에 호스트된 애플리케이션들에 N-API(노스바운드 API)(904)를 노출시킬 수 있다. 이 API는 UE(402) 상에서 실행하는 애플리케이션들에 노출될 것이다. 예를 들어, 그것은 펌웨어 관리 애플리케이션들, 멀티미디어 애플리케이션들, 차량 진단 애플리케이션들, 센서 측정들을 수집하는 애플리케이션들, 패키지들 또는 물품 목록의 상태를 추적하는 애플리케이션들, 서비스 계층들(즉, oneM2M ASN-CSE 또는 MN-SCE) 등에 의해 사용될 것이다. 예시적인 N-API들이 표들 3-7과 관련하여 설명된다.

애플리케이션 등록 API는 애플리케이션이 U-SCEF(902)를 사용할 것이라는 것을 U-SCEF(902)에 표시하기 위해 애플리케이션에 의해 호출된다. 이 API는 또 하나의 애플리케이션에 의해, 또는 GUI에 의해 UE(402) 기동 시에 트리거될 수 있다. 애플리케이션은 그것의 애플리케이션 식별자를 U-SCEF(902)에 제공할 것이고 U-SCEF(902)는 애플리케이션이 액세스하는 것이 허용된 U-SCEF(902)의 어떤 능력들을 표시함으로써 응답할 것이다.

애플리케이션 식별자는 OS에 의해 할당된 UE 로컬 애플리케이션 식별자이다.

능력들 응답은 애플리케이션이 U-SCEF(902)의 능력들(즉, 스케줄링, 배터리 레벨을 설정하는 것 등) 중 어느 것을 사용하거나 UE의 능력들의 서브셋을 간소화하는 것이 허용되지 않는다는 것을 표시할 수 있다. UE(402)는 U-SCEF(902) 또는 UE(402)를 구성하기 위해 사용될 수 있는 GUI, API 명령들, 또는 AT 명령들과 같은 사용자 인터페이스를 제공할 수 있으므로 그것은 어떤 애플리케이션들이 U-SCEF(902)에 액세스하는 것이 허용되는지를 안다.

애플리케이션 배터리 레벨 표시 API는 배터리 레벨을 U-SCEF(902)에 표시하기 위해 애플리케이션, OS, 또는 배터리 구동기에 의해 사용될 수 있다.

U-SCEF(902)는 EPC 인터워킹 서비스가 UE의 통신 스케줄, 불연속 수신(DRX) 사이클, 절전 모드(PSM) 사이클, 이동성 관리 타이머들 등을 구성할 때 배터리 레벨을 고려할 수 있도록 이 정보를 EPC 인터워킹 서비스에 전송할 수 있다. 대안적으로, UE(402)는 그것이 셀 선택 / 재선택을 얼마나 자주 수행하는지를 조정하기 위해 이 표시를 사용할 수 있다.

U-SCEF(902)는 네트워크로부터 어떤 통신 스케줄, DRX 사이클, PSM 사이클 등을 요구할지를 결정하기 위해 이 정보를 사용할 수 있다.

애플리케이션 원 타임 통신 스케줄 요구 API는 애플리케이션이 API 입력에서 설명된 데이터 교환을 시작할 수 있을 때를 U-SCEF(902)가 표시하는 것을 요구하기 위해 애플리케이션에 의해 사용된다.

이 API는 차량 게이트웨이 UE(402) 상에 호스트된 애플리케이션에 의해 사용될 수 있다. 애플리케이션은 네트워크로부터 펌웨어 업그레이드를 다운로드하기를 원할 수 있다. 한 예에서, 애플리케이션은 펌웨어 영상을 다운로드하는 최상의 시간이 언제인지를 U-SCEF(902)에 문의하기를 원할 것이다.

한 실시예에서, API는 비차단 동작을 야기할 수 있다. 애플리케이션은 요구된 통신이 시작될 때 호출될 수 있는 반환 기능에 대한 포인터를 제공할 수 있다.

대체 실시예에서, API 호출은 차단 동작을 야기할 수 있다. API는 시작 시간을 애플리케이션에 반환할 수 있다. 애플리케이션은 표시된 시작 시간에서 데이터 교환을 시작하는 것에 책임이 있을 것이다.

이 API가 호출될 때, U-SCEF(902)는 데이터 교환을 위한 최상의 시간을 독립적으로 결정할 수 있거나, 그것은 EPC 인터워킹 서비스가 최적의 통신 시간을 제공하기를 요구하기 위해 U-SCEF 원 타임 통신 스케줄 요구 S-API를 사용할 수 있다. 이 API가 애플리케이션에 의해 어떻게 사용될 수 있는지를 보여주는 호출 흐름이 도 10에 도시된다.

애플리케이션 주기적 시간 통신 스케줄 요구 API는 U-SCEF(902)가 API 입력에서 설명된 주기적 데이터 교환을 시작할 때를 표시하기를 요구하기 위해 애플리케이션 또는 GUI에 의해 사용된다.

이 API는 한 시간에 한번 데이터를 업로드하기를 원하는 감지 애플리케이션에 의해 사용될 수 있다. API는 통신 사이클을 언제 시작하는 것이 최적인지의 U-SCEF(902)로부터의 표시를 얻기 위해 사용될 수 있다. 예를 들어, 한 시간 후에 한 시간 동안 20분마다 한번보다 한 시간 후에 한 시간 동안 10분마다 한번 센서 데이터를 업로드하는 것이 더 최적일 수 있다.

한 실시예에서, API 호출은 비차단 방식으로 모델링될 수 있다. 애플리케이션은 요구된 통신 주기가 시작될 때 호출될 수 있는 반환 기능에 대한 포인터를 제공할 수 있다.

또 하나의 실시예에서, API 호출은 차단 방식으로 모델링될 수 있다. API는 시작 시간을 애플리케이션에 반환할 수 있다. 애플리케이션은 표시된 시작 시간에서 데이터 교환을 시작하는 것에 책임이 있을 것이다.

이 API가 호출될 때, U-SCEF(902)는 데이터 교환을 위한 최상의 시간을 독립적으로 결정할 수 있거나, 그것은 U-SCEF 주기적 통신 요구 S-API 요구를 사용하고 EPC 인터워킹 서비스가 최적의 통신 시간을 제공하게 할 수 있다. API가 애플리케이션에 의해 어떻게 사용될 수 있는지를 보여주는 호출 흐름이 도 11에 도시된다.

이 API는 주기적 방식으로 통신하기를 원하는 UE(402) 상에서 실행하는 하나 보다 많은 애플리케이션이 있을 때 특히 유용하다는 점에 주목한다. U-SCEF(902)는 그들의 통신 주기들이 정렬되도록 애플리케이션들을 동기화할 수 있다. 그들의 통신 주기들을 정렬함으로써, UE(402)는 더 오랜 주기들 동안 슬립할 수 있다(즉, 더 오랜 주기들 동안 DRX 또는 PSM에 머무를 수 있다). 통신 패턴들을 정렬하는 것은 2개의 애플리케이션들에게 서로 동시에 또는 바로 직후에 시작하라고 알리는 것을 의미할 수 있다.

애플리케이션 이동성 표시 API는 예상된 이동성 레벨을 U-SCEF(902)에 표시하기 위해 애플리케이션 또는 GUI에 의해 사용된다. 표 7 내의 파라미터들이 예상된 이동성 레벨를 표시하기 위해 사용될 수 있다.

U-SCEF(902)는 EPC 인터워킹 서비스가 UE의 이동성 관리 타이머들, 페이징 영역 등을 구성할 때 예상된 이동성 레벨을 고려할 수 있도록 이 정보를 EPC 인터워킹 서비스에 전송할 수 있다.

U-SCEF(902)는 UE의 이동성 관리 타이머들, PSM 타이머들, DRX 타이머들 등을 어떻게 설정할지를 결정하기 위해 이 정보를 사용할 수 있다. U-SCEF(902)는 이동성 정보 또는 추천된 타이머 값들을 UE(402)에 통과시키기 위해 API, AT 명령을 사용할 수 있다. 대안적으로, UE(402)는 그것이 셀 선택 / 재선택을 얼마나 자주 수행하는지를 조정하기 위해 이 표시를 사용할 수 있다.

이 API는 차량 게이트웨이 플랫폼 상에서 실행하는 애플리케이션에 유용할 것이다. 애플리케이션은 차량이 주차되어 있고, 충전소에 플러그되고, 교통 체증 등에 있을 때 비교적 고정이라는 것을 U-SCEF(902)에 표시할 수 있다. UE(402) 및 EPC는 다음에 UE의 이동성 관리 타이머들, PSM 타이머들, DRX 타이머들, 페이징 영역 등을 보다 효율적으로 구성할 수 있다.

이 API는 또한 자동 판매기 애플리케이션에 유용할 것이다. 애플리케이션은 자동 판매기가 플러그 인될 때마다 그것이 고정이라는 것을 U-SCEF(902)에 표시할 수 있다.

다수의 애플리케이션들이 U-SCEF(902)에 상이한 이동성 레벨들을 표시하면 U-SCEF(902)는 상이한 표시들을 집합하고 이동성 표시들의 단일 세트를 EPC 인터워킹 서비스에 제공할 것이다. U-SCEF(902)는 이동성의 "최고" 레벨을 표시하는 표시들 및 최대 영역에 걸쳐 이동성을 표시한 표시들을 사용하거나, 또는 표시된 영역들의 수퍼 세트를 사용하기를 선택할 수 있다.

U-SCEF(902)는 EPC 인터워킹 서비스와 통신하기 위해 S-API(Southbound API)를 사용할 수 있다. U-SCEF(902)는 IP 기반 접속을 통해 EPC 인터워킹 서비스에 메시지들을 송신하기 위해 사용될 수 있다. 대안적으로, S-API는 제어 정보를 코어 네트워크 노드에 송신할 UE의 모뎀에 구성 정보를 송신하기 위해 사용될 수 있다. 예시적인 S-API들이 표들 8-12와 관련하여 아래에 논의된다.

UE(402)가 EPC 네트워킹 서비스에 액세스하기 위해 사용될 수 있는 APN에 PDN 접속을 확립한 후에, UE(402)는 초기 등록 메시지를 EPC 인터워킹 서비스에 송신하기 위해 U-SCEF 등록 API를 사용한다.

한 실시예에서, 단지 하나의 U-SCEF(902)가 디바이스 상에 상주한다. U-SCEF(902)는 그것의 3GPP 외부 식별자로 자체를 식별할 수 있다. U-SCEF(902) 등록 절차가 아래 사용들 경우들에 나타내진다.

U-SCEF 배터리 레벨 표시 API는 EPC 인터워킹 서비스에 배터리 레벨을 표시하기 위해 U-SCEF(902)에 의해 사용될 수 있다.

EPC 인터워킹 서비스는 UE의 통신 스케줄, DRX 사이클, PSM 사이클, 이동성 관리 타이머들 등을 구성할 때 배터리 레벨을 고려할 수 있다.

EPC 인터워킹 서비스는 네트워크로부터 어떤 통신 스케줄, DRX 사이클, PSM 사이클, 이동성 관리 타이머들 등을 요구할지를 결정하기 위해 이 정보를 사용할 수 있다.

U-SCEF 원 타임 통신 스케줄 요구 API는 데이터 전달이 허용될 때의 표시를 요구하기 위해 U-SCEF(902)에 의해 사용될 수 있다.

UE(402) 상의 다수의 애플리케이션들이 원 타임 데이터 전달을 요구하면(즉, 5.1.1.3의 애플리케이션 원 타임 통신 스케줄 요구 API를 통해), U-SCEF(902)는 요구를 EPC 인터워킹 서비스로의 단일 요구로 통합할 수 있다.

U-SCEF 주기적 시간 통신 스케줄 요구 API는 UE(402)가 API 입력에서 설명된 주기적 데이터 교환을 시작할 때를 EPC 인터워킹 서비스가 표시하기를 요구하기 위해 U-SCEF(902)에 의해 사용될 수 있다.

UE(402) 상의 다수의 애플리케이션들이 주기적 데이터 전달을 요구하면(즉, 애플리케이션 원 타임 통신 스케줄 요구 API를 통해), U-SCEF(902)는 요구를 EPC 인터워킹 서비스(1002)로의 단일 요구로 통합할 수 있다. U-SCEF(902)는 그들의 통신 주기들이 정렬되도록 애플리케이션들을 동기화할 수 있다. 그들의 통신 주기들을 정렬함으로써, UE(402)는 더 오랜 주기들 동안 슬립할 수 있다(즉, 더 오랜 주기들 동안 DRX 또는 PSM에 머무를 수 있다). 통신 패턴들을 정렬하는 것은 2개의 애플리케이션들에게 서로 동시에 또는 바로 직후에 시작하라고 알리는 것을 의미할 수 있다.

U-SCEF 이동성 표시 API는 예상된 이동성 레벨을 EPC 인터워킹 서비스(1002)에 표시하기 위해 U-SCEF(902)에 의해 사용된다.

U-SCEF(902)는 EPC 인터워킹 서비스(1002)가 UE의 이동성 관리 타이머들, 페이징 영역 등을 구성할 때 예상된 이동성 레벨을 고려할 수 있도록 이 정보를 EPC 인터워킹 서비스에 전송할 수 있다.

모뎀 API는 애플리케이션 또는 EPC 인터워킹 서비스로부터의 입력에 기초하여 모뎀을 구성하기 위해 U-SCEF(902)에 의해 사용될 수 있다.

베어러가 주기적 통신 또는 원-타임 스케줄된 다운로드를 위해 확립될 때, U-SCEF(902)는 3GPP 모뎀이 통신하기 위해 사용될 베어러를 수정할 때 네트워크에 정책 참조 번호를 제공할 수 있도록 정책 참조 번호를 3GPP 모뎀에 제공할 수 있다.

EPC 인터워킹 서비스(1002)가 U-SCEF(902)에 이동성 관리 타이머들 또는 MM 참조 번호를 제공할 때, U-SCEF(902)는 추적 영역 업데이트와 같은 MM 절차를 수행할 때 모뎀이 그들을 네트워크에 제공할 수 있도록 타이머 값들 또는 MM 참조 번호를 3GPP 모뎀에 제공할 수 있다.

도 9에 도시한 바와 같이, U-SCEF(902)는 EPC 인터워킹 서비스(1002)와 통신하고 노출된 서비스들에 액세스하기 위해 확립되는 PDN 접속 또는 데이터 네트워크 접속을 사용할 수 있다. EPC 인터워킹 서비스는 가상화된 네트워크 기능이다. UE의 운영 체제 또는 SIM 카드는 PDN 접속 또는 데이터 네트워크 접속 또는 네트워크 슬라이스 접속을 확립할 때 U-SCEF(902)가 사용하여야 하는 APN 또는 데이터 네트워크 명 또는 네트워크 슬라이스 명 또는 네트워크 슬라이스 유형 명 또는 서비스 명 또는 서비스 설명자를 구비할 수 있다. HSS(302) 내의 UE의 가입 정보는 UE(402)가 이 APN 또는 데이터 네트워크에 액세스하는 것이 허용되거나 서비스 노출 서비스에 액세스하는 것이 허용된다는 것을 표시할 수 있다. UE(402)가 부착할 때, 이동성 관리 엔티티(MME)(304)는 PDN 및 EPC 인터워킹 서비스에 액세스하는 것이 허용되는지를 확인하기 위해 UE의 가입 정보를 체크할 수 있다. 그러므로, 기존의 PDN 접속 절차 및 UE의 가입 내의 APN 정보는 허가되지 않는 UE가 EPC 인터워킹 서비스(1002)에 액세스하는 것을 방지하기 위해 사용될 수 있다. 5G 네트워크에서, UE(402)가 부착할 때, 네트워크 기능은 UE가 네트워크 슬라이스에 액세스하는 것이 허용되고, 데이터 네트워크에 액세스하는 것이 허용되고, 서비스 노출 기능에 액세스하는 것이 허용되는지를 확인하기 위해 UE의 가입 정보를 체크할 수 있다. 이 체크를 수행하는 네트워크 기능은 CNSF일 수 있다.

대안적인 방법들이 UE(402)가 EPC 인터워킹 서비스에 액세스하게 하고 허가되지 않은 UE가 EPC 인터워킹 서비스(1002)에 액세스하는 것을 방지하기 위해 사용될 수 있다.

대안적인 실시예에서, U-SCEF(902) 또는 SIM 카드는 식별자, IP 어드레스, 또는 EPC 인터워킹 서비스(1002)의 FQDN을 구비할 수 있고 U-SCEF(902)는 PDN 접속에 액세스하기 위해 그것의 디폴트 PDN 접속 또는 일부 다른 PDN 접속을 사용할 수 있다. EPC 인터워킹 서비스(1002)는 UE(402)가 서비스에 액세스하는 것이 허가되는 것을 체크하는 임무를 할 수 있다.

대안적인 실시예에서, U-SCEF(902)와 EPC 인터워킹 서비스(1002) 간의 시그널링 및 정보 교환은 사용자 평면 위에서 일어나지 않을 수 있으므로 PDN 접속을 필요로 하지 않을 것이다. 대신에, EPC 인터워킹 서비스(1002)는 독립적인 코어 네트워크 기능일 수 있거나 그것은 MME(304), SCEF(102), 머신형 통신 인터워킹 기능(MTC-IWF), 또는 PCRF(104)와 같은 코어 네트워크 노드 내에 상주할 수 있다. EPC 인터워킹 서비스(1002)는 가상화된 기능으로서 구현될 수 있다. U-SCEF(902)는 NAS 메시징과 같은 제어 평면 시그널링을 통해 EPC 인터워킹 서비스(1002)와 통신할 수 있다.

EPC 인터워킹 서비스(1002)는 UE(402)(U-SCEF)와 코어 네트워크(SCEF) 간의 "조정자" 역할을 한다. EPC 인터워킹 서비스(1002)는 UE(402)로부터 조정 요구들을 받아들이고, 코어 네트워크와 협상하고 UE(402)가 그것의 통신을 더 최적하게 스케줄할 수 있도록 UE(402)에 피드백을 제공한다. EPC 인터워킹 서비스(1002)는 SCEF(102)의 일부일 수 있다는 점에 주목한다. 바꾸어 말하면, U-SCEF(902)와 SCEF(102)는 직접 통신할 수 있다.

도 9에 도시된 기능성은 메모리 내에 저장되고, 후술되는 도 14c 또는 도 14d에 도시된 것들 중 하나와 같은 M2M 네트워크의 노드(서버, 게이트웨이 디바이스, 또는 다른 컴퓨터 시스템)의 프로세서 상에서 실행하는 소프트웨어(즉, 컴퓨터 실행가능 명령어들)의 형태로 구현될 수 있음을 이해해야 한다.

다음에 일부 사용 경우들에 대해 설명한다. 도 10에 도시한 것과 같은, 스케줄된 다운로드/업로드 절차가 네트워크와의 데이터 전달을 스케줄하기 위해 UE(402)에 의해 사용된다. 이 절차는 특히 다음의 상황들 하에서 유용하다.

UE(402)가 다음 24시간 내에 펌웨어 영상을 다운로드하기를 원한다고 가정한다. 이 절차는 그것이 다운로드를 수행할 필요가 있다는 것을 네트워크에 알리고 다운로드를 언제 수행할지를 네트워크가 UE(402)에게 알리게 하기 위해 UE(402)에 의해 사용될 수 있다. 네트워크는 UE(402)에게 비교적 낮은 트래픽 볼륨이 예상되는 시간에 영상을 다운로드하라고 알릴 수 있다.

UE(402)가 큰 볼륨의 센서 데이터, 영상들, 또는 비디오에 최근 로그하였고, 그것이 서버에 정보를 업로드하기를 원한다고 가정한다. 이 절차는 그것이 업로드를 수행할 필요가 있다는 것을 네트워크에 알리고 업로드를 언제 수행할지를 네트워크가 UE(402)에게 알리게 하기 위해 UE(402)에 의해 사용될 수 있다. 네트워크는 UE(402)에게 비교적 낮은 트래픽 볼륨이 예상되는 시간에 영상을 업로드하라고 알릴 수 있다.

도 10의 단계 0에서, U-SCEF(902)는 EPC 인터워킹 서비스(1002)와 접속을 확립한다. 이것은 U-SCEF(902)가 EPC 인터워킹 서비스(1002)와 통신하기 위해 특별 PDN 접속 또는 전용 베어러를 확립한다는 것을 의미할 수 있다. 접속이 확립될 때, U-SCEF(902)는 EPC 인터워킹 서비스(1002)에 등록하기 위해 U-SCEF 등록 API를 사용한다. EPC 인터워킹 서비스(1002)는 지원되고 U-SCEF(902)가 액세스하는 것이 허용되는 특징들의 리스트로 응답할 수 있다.

도 10의 단계 1에서, 애플리케이션 #2는 U-SCEF(902)에 그것의 아이덴티티를 등록하고 U-SCEF(902)가 애플리케이션이 액세스하게 할 특징들의 리스트를 획득하기 위해 애플리케이션 등록 N-API를 사용한다.

도 10의 단계 2에서, 애플리케이션 #2는 그것이 5 PM 전에 2GB의 데이터를 다운로드하고 싶어 한다는 것을 U-SCEF(902)에 표시하기 위해 애플리케이션 원 타임 통신 스케줄 N-API를 사용한다.

도 10의 단계 3에서, U-SCEF(902)는 EPC 인터워킹 서비스(1002)로부터 통신 시간을 요구하기 위해 그것의 인터워킹 PDN 접속 및 U-SCEF 원 타임 통신 스케줄 요구 S-API를 사용한다.

API 호출은 UE(402)가 그것의 외부 식별자와 그 자체를 식별하게 한다. EPC 인터워킹 서비스(1002)가 단계 4에서 SCEF(102)에 요구를 전송할 때, EPC 인터워킹 서비스(1002)는 SCEF(102)에 외부 식별자 및 발신 IP 어드레스를 제공할 수 있다. SCEF(102)는 소스 UE(402)를 검증(인증)하기 위해 발신 IP 어드레스 및 외부 식별자를 사용할 수 있다. 예를 들어, SCEF(102)는 IP 어드레스가 외부 식별자와 관련된 UE(402)에 속한다는 것을 검증하기 위해 HSS(302), P-GW(404), PCRF(104), DHCP 서버, 또는 DNS 서버에 질의할 수 있다.

도 10의 단계 4에서, (AS/SCS/AF/MTC 서버/CSE로서 동작하는) EPC 인터워킹 서비스(1002)는 SCEF(102)에 데이터 전달 요구를 전송할 것이다.

도 10의 단계 5에서, SCEF(102)는 2.3에서 발견되는 것과 같은 절차를 사용하여 EPC로부터 데이터 전달 시간을 요구할 것이다. 2.3에서 설명된 바와 같이, SCEF(102)는 전달을 수행하기 위한 시간 윈도우를 포함할 전달 정책 제의 및 전달 제의와 연관된 SM 참조 ID를 획득할 것이다.

도 10의 단계 6에서, SCEF(102)는 데이터 전달 제의로 EPC 인터워킹 서비스(1002)에 응답할 것이다. 참조 S2-151426에서 설명된 바와 같이, SCEF(102)는 전달을 수행하기 위한 시간 윈도우를 포함할 전달 정책 제의 및 전달 제의와 연관된 SM 참조 ID를 획득할 것이다.

도 10의 단계 7에서, EPC 인터워킹 서비스(1002)는 U-SCEF(902)에 데이터 전달 제의 및 SM 참조 ID를 전송할 것이다.

도 10의 단계 8a에서, U-SCEF(902)는 애플리케이션 #2에 데이터 전달 제의 및 SM 참조 ID를 전송할 것이다.

도 10의 단계 8b에서, U-SCEF(902)는 데이터 전달 제의 내에 표시된 시간까지 대기하고 데이터 전달이 시작되어야 한다는 표시를 애플리케이션 #2에 송신한다.

U-SCEF(902)가 데이터 전달 제의를 수신하고 나서, 그것은 UE(402)가 제의 내에 표시된 시간까지 이동 네트워크와 통신할 필요가 없을 것이라는 것을 추론할 수 있다. 그러므로, 데이터 전달 시간에 가까워질 때까지 슬립 상태에 들어가기를 선택할 수 있다. 슬립 상태에 들어가면 클럭 주파수들을 낮추고, 메모리들 또는 메모리들의 일부를 턴 오프하고, 메모리들 또는 모뎀의 일부들에의 전압을 낮추고, 디스플레이들을 어둡게 하는 등이 수반될 수 있다.

도 10의 단계 9a에서, 애플리케이션 #2는 U-SCEF(902)로부터 데이터 전달 제의를 수신하고, 표시된 시간까지 대기한 후에, 데이터를 전달할 것이다.

도 10의 단계 9b에서, 애플리케이션 #2는 그것이 U-SCEF(902)로부터 표시를 수신할 때까지 대기한 후에 데이터 전달을 시작할 것이다.

도 10의 단계 10에서, 애플리케이션 #2는 애플리케이션 서버와의 그것의 데이터 전달을 시작할 것이다. 데이터 전달은 UE의 디폴트 PDN 접속 상에서 이루어질 것이다.

애플리케이션 서버와의 데이터 전달을 시작하기 전에, UE(402)는 애플리케이션 서버에 및 애플리케이션 서버로부터 데이터를 전달하기 위해 사용된 PDN 접속(즉, EPC 인터워킹 서비스(1002))과 통신하기 위해 사용되는 PDN 접속은 아님) 상에서 MME(304)에 베어러 리소스 활성화 수정 메시지를 송신할 수 있다. 베어러 리소스 활성화 수정 절차는 참조 3GPP TS 23.401의 섹션 5.4.5에 상세히 설명되어 있다. 베어러 리소스 수정 요구 메시지는 참조 3GPP TS 24.301("이볼브드 패킷 시스템(EPS)을 위한 비-액세스-스트라텀(NAS) 프로토콜"; 스테이지 3)의 섹션 8.3.10에 상세히 설명되어 있다. UE(402)가 네트워크에 전달 정책 참조 번호를 표시할 수 있도록 새로운 정보 요소가 이 메시지에 추가될 수 있다. 참조 3GPP TS 23.401의 섹션 5.4.5의 흐름 내의 메시지들은 MME(304)가 S-GW(406)에 전달 정책 참조 번호를 통과시키기 위해 베어러 리소스 명령을 사용하고 S-GW(406)가 P-GW(404)에 전달 정책 참조 번호를 통과시키기 위해 베어러 리소스 명령을 사용하도록 업데이트될 수 있다. P-GW(404)는 PCRF(104)에 전달 정책 참조 번호를 통과시키고 참조 번호는 어떤 PCC 규칙들이 활성화될 것인지를 결정하기 위해 사용될 수 있다. 네트워크(즉, PCEF(206))는 참조 번호가 알려진 시간에 시작할 통신 스케줄 요구돠 연관된다는 것을 인식한다. 네트워크(즉, PCRF(104))는 QoS가 미리 배정된 시간까지 제공될 필요가 없고 통신이 완료할 때 QoS가 더 이상 제공될 필요가 없을 것이라는 것을 인식한다. PCRF(104)는 통신이 완료되거나 타이머가 만료할 때 베어러를 자동으로 종료할 수 있다.

대안적으로, SCEF(102)와의 데이터 전달 및 통신은 동일한 PDN 접속 상에서 일어날 수 있다.

애플리케이션 배터리 레벨 N-API 및 U-SCEF 배터리 레벨 S-API는 통신을 스케줄하기 전에 EPC 인터워킹 서비스(1002)에 UE의 배터리 레벨을 표시하기 위해 사용될 수 있다. EPC 인터워킹 서비스(1002) 및 코어 네트워크는 UE(402)가 통신하는 최적 시간을 결정할 때 배터리 레벨을 고려할 수 있다. 예를 들어, 낮은 배터리 레벨은 UE(402)에게 통신을 곧 시작하라고 알려야 하는 것을 표시할 수 있다.

도 11에 도시한 것과 같은 이 절차가 네트워크와의 주기적 통신을 스케줄하기 위해 UE(402)에 의해 사용된다. 다음의 시나리오를 고려해보자.

UE(402)는 2개의 애플리케이션들을 호스트한다. 하나의 애플리케이션(앱 1)은 5초마다 한번 화상을 캡처하는 카메라에 연관된다. 제2 애플리케이션(앱 2)은 10초마다 한번 데이터를 업로드하는 진단 센서에 연관된다. 각각의 애플리케이션은 그들이 주기적 통신을 수행하기를 원한다는 것을 U-SCEF(902)에 표시할 것이고 U-SCEF(902)는 그들이 그들의 주기적 통신을 시작하여야 할 때를 각각의 애플리케이션에 표시할 것이다. 그러므로, U-SCEF(902)는 그들이 그들의 각각의 서버(들)와 동일한 시간에 통신하거나 동일한 시간에 가깝게 통신하도록 애플리케이션을 구성할 수 있다. 2개의 애플리케이션들이 통신을 행할 때, UE(402)는 절전, 또는 슬립 상태로 갈 수 있다. 애플리케이션들이 동일한 시간에, 또는 동일한 시간에 가깝게 통신하는 것을 보장함으로써, UE가 절전, 또는 슬립 모드를 왔다 갔다 하는 전이들이 감소된다.

도 11 내의 절차는 U-SCEF(902)가 네트워크와의 UE의 주기적 통신을 어떻게 조정할 수 있는지를 보여준다. 절차는 네트워크가 그것의 주기적 통신을 위한 최적 시작 시간으로 UE(402)를 구성하게 한다. 그러므로, 많은 UE들이 주기적 통신을 수행하기를 원하면, 네트워크는 동시에 통신하는 UE들의 수가 감소되도록 UE들을 구성할 수 있다.

요악하면, UE(402) 상의 애플리케이션들은 그들의 원하는 주기적 통신 스케줄을 위해 U-SCEF(902)에 질문할 수 있다. U-SCEF(902)는 집합된 스케줄을 형성하기 위해 모든 애플리케이션들의 원하는 스케줄을 조합하고 집합된 통신 스케줄에 기초하여 최적 시작 시간을 위해 네트워크에 질문할 수 있다. 네트워크는 U-SCEF(902)에 최적 시작 시간을 알릴 수 있고 U-SCEF(902)는 또한 UE(402)가 최적 시작 시간에 통신하도록 애플리케이션들을 구성할 수 있다.

도 11의 단계 0에서, U-SCEF(902)는 EPC 인터워킹 서비스와 접속을 확립한다. 이것은 U-SCEF(902)가 EPC 인터워킹 서비스와 통신하기 위해 특별 PDN 접속 또는 전용 베어러를 확립한다는 것을 의미할 수 있다. 접속이 확립될 때, U-SCEF(902)는 EPC 인터워킹 서비스(1002)에 등록하기 위해 U-SCEF 등록 API를 사용한다. EPC 인터워킹 서비스(1002)는 지원되고 U-SCEF(902)가 액세스하는 것이 허용되는 특징들의 리스트로 응답할 수 있다.

도 11의 단계 1에서, 애플리케이션 #1은 U-SCEF(902)에 그것의 아이덴티티를 등록하고 U-SCEF(902)가 애플리케이션이 액세스하게 할 특징들의 리스트를 획득하기 위해 애플리케이션 등록 N-API를 사용한다.

도 11의 단계 2에서, 애플리케이션 #2는 U-SCEF(902)에 그것의 아이덴티티를 등록하고 U-SCEF(902)가 애플리케이션이 액세스하게 할 특징들의 리스트를 획득하기 위해 애플리케이션 등록 N-API를 사용한다.

도 11의 단계 3에서, 애플리케이션 #1은 그것이 5초마다 1Kbyte의 데이터를 업로드하고 싶어 한다는 것을 U-SCEF(902)에 표시하기 위해 애플리케이션 주기적 통신 스케줄 N-API를 사용한다

도 11의 단계 4에서, 애플리케이션 #2는 그것이 10초마다 3Kbyte의 데이터를 업로드하고 싶어 한다는 것을 U-SCEF(902)에 표시하기 위해 애플리케이션 주기적 통신 스케줄 N-API를 사용한다.

도 11의 단계 5에서, U-SCEF(902)는 집합된 통신 스케줄을 형성한다. 집합 통신 스케줄은 UE(402)가 5초마다 4Kbyte의 데이터를, 또는 또 하나의 예에서, 10초마다 5Kbyte의 데이터를 업로드하기를 원한다는 것을 표시한다.

도 11의 단계 6에서, U-SCEF(902)는 네트워크와의 주기적 통신을 스케줄하기 위해 그것의 인터워킹 PDN 접속 및 U-SCEF 주기적 통신 스케줄 요구 S-API를 사용한다.

도 11의 단계 7에서, EPC 인터워킹 서비스(1002)는 AS/SCS로서 동작하고 네트워크에 주기적 통신 스케줄을 제공할 것이다.

도 11의 단계 8에서, SCEF(102)는 통신 패턴에 관한 정보로 네트워크를 구성할 것이다.

도 11의 단계 9에서, SCEF(102)는 주기적 통신 패턴을 알리는 응답을 네트워크로부터 수신할 것이다. 이 응답은 주기적 통신 패턴을 위한 최적 시작 시간을 포함하도록 향상될 수 있다는 점에 주목한다. 예를 들어, 그것은 통신이 한 시간 후에 10분마다 시작하여야 한다는 것을 표시할 수 있다. 응답은 또한 정책 SM 참조 ID를 포함하도록 업데이트될 수 있다.

도 11의 단계 10에서, EPC 인터워킹 서비스(1002)는 U-SCEF(902)에 주기적 통신 시작 시간 및 SM 참조 ID를 전송할 것이다.

도 11의 단계 11a에서, U-SCEF(902)는 애플리케이션들 1 및 2에 데이터 전달 시작 시간 및 SM 참조 ID를 전송할 것이다.

도 11의 단계 11b에서, U-SCEF(902)는 데이터 전달 제의 내에 표시된 시간까지 대기하고 데이터 전달이 시작되어야 한다는 표시를 애플리케이션들 1 및 2에 송신한다.

U-SCEF(902)가 데이터 전달 제의를 수신하고 나서, 그것은 UE(402)가 제의 내에 표시된 시간까지 이동 네트워크와 통신할 필요가 없을 것이라는 것을 추론할 수 있다. 그러므로, 데이터 전달 시간에 가까워질 때까지 슬립 상태에 들어가기를 선택할 수 있다. 슬립 상태에 들어가면 클럭 주파수들을 낮추고, 메모리들 또는 메모리들의 일부를 턴 오프하고, 메모리들 또는 모뎀의 일부들에의 전압을 낮추고, 디스플레이들을 어둡게 하는 등이 수반될 수 있다.

도 11의 단계 12a에서, 애플리케이션들 1 및 2는 U-SCEF(902)로부터 데이터 전달 제의를 수신하고, 표시된 시간까지 대기한 후에, 데이터를 전달할 것이다.

도 11의 단계 12b에서, 애플리케이션들 1 및 2는 그들이 U-SCEF(902)로부터 표시를 수신할 때까지 대기한 후에 데이터 전달을 시작한다.

도 11의 단계 13에서, 애플리케이션들 1 및 2는 애플리케이션 서버와의 그것의 데이터 전달을 시작한다. 데이터 전달은 UE의 디폴트 PDN 접속 상에서 이루어질 것이다.

애플리케이션 서버와의 데이터 전달을 시작하기 전에, UE(402)는 MME(304)에 베어러 리소스 활성화 수정 메시지를 송신할 수 있다. 베어러 리소스 활성화 수정 절차는 참조 3GPP TS 23의 섹션 5.4.5에 상세히 설명되어 있다. 베어러 리소스 수정 요구 메시지는 참조 3GPP TS 24.301의 섹션 8.3.10에 상세히 설명되어 있다. UE(402)가 네트워크에 전달 정책 참조 번호를 표시할 수 있도록 새로운 정보 요소가 이 메시지에 추가될 수 있다. 참조 3GPP TS 23.401의 섹션 5.4.5의 흐름 내의 메시지들은 MME(304)가 S-GW(406)에 전달 정책 참조 번호를 통과시키기 위해 베어러 리소스 명령을 사용하고 S-GW(406)가 P-GW(404)에 전달 정책 참조 번호를 통과시키기 위해 베어러 리소스 명령을 사용하도록 업데이트될 수 있다. P-GW(404)는 PCRF(104)에 전달 정책 참조 번호를 통과시키고 참조 번호는 어떤 PCC 규칙들이 활성화될 것인지를 결정하기 위해 사용될 수 있다. 네트워크(즉, PCEF(206))는 참조 번호가 알려진 간격들로 시작할 주기적 통신 스케줄 요구와 연관된다는 것을 인식한다. 네트워크(즉, PCRF(104))는 QoS가 예상된 통신 윈도우 밖에 제공될 필요가 없을 것이라는 것을 인식한다. PCRF(104)는 설정된 수의 통신 사이클들 후에 또는 미리 결정된 수의 통신 사이클들이 UE(402)에 의해 놓쳐진 후에 베어러를 종료할 수 있다.

대안적으로, SCEF(102)와의 데이터 전달 및 통신은 동일한 PDN 접속 상에서 일어날 수 있다. 애플리케이션은 EPC 인터워킹 서비스(1002)에 새로운 주기적 통신 스케줄을 통과시키기 위해 애플리케이션 주기적 통신 스케줄 N-API를 사용함으로써 그것의 주기적 통신 스케줄을 변경할 수 있다.

도 12에 도시한 것과 같은, 이동성 표시들 절차가 U-SCEF(902)에 그들의 예상된 이동성을 표시하기 위해 UE(402) 상의 애플리케이션(들)에 의해 사용된다. 예를 들어, 차량 게이트웨이 상에서 실행하는 애플리케이션은 UE의 위치, 예상된 이동성 레벨, 예상된 평균 속도, 및 UE(402)가 고정인지를 알 수 있다. 예를 들어, 애플리케이션은 차가 주차되어 있거나 충전소에 플러그되어 있으면 UE(402)가 고정이라는 것을 표시할 수 있다. 애플리케이션은 UE(402)가 고속도로 상에 있고 어떤 때는 고속으로 이동할 것 같다는 것을 검출하기 위해 GPS를 사용할 수 있다.

U-SCEF(902)는 모뎀의 이동성 관리 타이머들을 조정하기 위해 이 정보를 사용할 수 있다. 예를 들어, U-SCEF(902)는 추적 영역 업데이트들(TAU)의 타이밍을 제어하기 위해 사용되는 T3412 및 T3430 타이머들에 대한 값들을 결정하기 위해 이 정보를 사용할 수 있다. 이들 타이머는 참조 3GPP TS 24.301에서 정의된다.

U-SCEF(902)는 또한 정보가 예를 들어, 이동성 관리 타이머들을 설정하기 위해 네트워크에서 사용될 수 있도록 EPC 인터워킹 서비스(1002)에 이동성 정보를 통과시킬 수 있다.

도 12의 단계 0에서, U-SCEF(902)는 EPC 인터워킹 서비스와 접속을 확립한다. 이것은 U-SCEF(902)가 EPC 인터워킹 서비스(1002)와 통신하기 위해 특별 PDN 접속 또는 전용 베어러를 확립한다는 것을 의미할 수 있다. 접속이 확립될 때, U-SCEF(902)는 EPC 인터워킹 서비스(1002)에 등록하기 위해 U-SCEF 등록 API를 사용할 것이다. EPC 인터워킹 서비스(1002)는 지원되고 U-SCEF(902)가 액세스하는 것이 허용되는 특징들의 리스트로 응답할 수 있다.

도 12의 단계 1에서, 애플리케이션 #1은 U-SCEF(902)에 그것의 아이덴티티를 등록하고 U-SCEF(902)가 애플리케이션이 액세스하게 할 특징들의 리스트를 획득하기 위해 애플리케이션 등록 N-API를 사용한다.

도 12의 단계 2에서, 애플리케이션 #1은 U-SCEF(902)에 예상된 이동성 특성들을 표시하기 위해 애플리케이션 이동성 표시 N-API를 사용한다.

도 12의 단계 3a에서, U-SCEF(902)는 모뎀들 이동성 관리 타이머들을 구성하고, 예를 들어, U-SCEF(902)는 추적 영역 업데이트들(TAU)의 타이밍을 제어하기 위해 사용되는 T3412 및 T3430 타이머들을 조정하기 위해 이 정보를 사용할 수 있다. 이들 타이머는 참조 3GPP TS 24.301에서 정의된다. 대안적으로, UE(402)는 그것이 셀 선택 / 재선택을 얼마나 자주 수행하는지를 조정하기 위해 이 표시를 사용할 수 있다.

도 12의 단계 3b에서, U-SCEF(902)는 EPC 인터워킹 서비스(1002)에 이동성 표시 정보를 통과시키기 위해 U-SCEF 이동성 표시 N-API를 사용한다.

도 12의 단계 4에서, EPC 인터워킹 서비스(1002)는 AS/SCS로서 동작하고 네트워크에 이동성 표시자들을 제공할 것이다.

도 12의 단계 5에서, SCEF(102)는 이동성 표시자들에 관한 정보로 네트워크를 구성할 것이다.

도 12의 단계 6에서, SCEF(102)는 이동성 표시자들을 알리는 응답을 네트워크로부터 수신할 것이다. 이 응답은 이동성 패턴 참조 ID를 포함하도록 향상될 수 있다. MM 참조 ID는 나중 시간에 (즉, UE(402)에 의해) 네트워크에 제공될 수 있고 네트워크는 그에 따라 그것의 이동성 관리 타이머들을 설정할 수 있다. 대안적으로, 이 응답은 T3412 및 T3442와 같은 이동성 관리 타이머들을 제공하도록 향상될 수 있다.

도 12의 단계 7에서, 네트워크는 이동성 표시자들에 기초하여 UE의 MM 타이머들을 조정할 수 있다.

도 12의 단계 8에서, EPC 인터워킹 서비스(1002)는 U-SCEF 이동성 표시 N-API에 응답할 것이다. 응답은 MM 타이머 값들 및 MM 참조 ID를 포함할 수 있다.

도 12의 단계 9에서, U-SCEF(902)는 모뎀에 새로운 MM 타이머 값들 및 MM 참조 ID를 제공할 수 있다. 모뎀은 그것이 추적 영역 업데이트와 같은 MM 절차를 수행하는 다음 시간에 그것의 MM 타이머들을 조정할 수 있다. 모뎀은 그것이 추적 영역 업데이트와 같은 MM 절차를 수행할 때 네트워크에 MM 참조 ID를 또한 제공할 수 있다. MM 참조 ID는 최적 MM 타이머 값들을 결정하기 위해 네트워크(즉, MME(304))에 의해 사용될 수 있다.

나중에, 애플리케이션은 EPC 인터워킹 서비스(1002)에 새로운 이동성 표시 정보를 통과시키기 위해 U-SCEF 이동성 표시 N-API를 사용하여 그것의 이동성 상태를 변경할 수 있다.

도 10-도 12에 도시된 단계들을 수행하는 엔티티들은 도 14c 또는 도 14d에 도시된 것들과 같은 네트워크 노드 또는 컴퓨터 시스템의 메모리 내에 저장되고, 또는 그 프로세서 상에서 실행하는 소프트웨어(즉, 컴퓨터 실행가능 명령어들)의 형태로 구현될 수 있는 논리적 엔티티들이라는 것이 이해된다. 즉, 도 10-도 12에 도시된 방법(들)은 노드의 프로세서에 의해 실행될 때, 도 10-도 12에 도시된 단계들을 수행하는, 도 14c 또는 도 14d에 도시된 노드 또는 컴퓨터 시스템과 같은 네트워크 노드의 메모리 내에 저장된 소프트웨어(예를 들어, 컴퓨터 실행가능 명령어들)의 형태로 구현될 수 있다. 도 10-도 12에 도시된 임의의 송신 및 수신 단계들은 노드의 프로세서의 제어 하에서의 노드의 통신 회로 및 그것이 실행하는 컴퓨터 실행가능 명령어들(예를 들어, 소프트웨어)에 의해 수행될 수 있다는 것이 또한 이해된다. 도 10-도 12 내의 엔티티들은 가상화된 네트워크 기능들의 형태로 구현될 수 있다는 것이 이해된다.

그래픽 사용자 인터페이스들(GUI들)과 같은 인터페이스들은 사용자가 이동 코어 네트워크 및 UE(402) 애플리케이션 인터워킹에 관련된 기능성들을 제어 및/또는 구성하는 것을 지원하기 위해 사용될 수 있다. 도 13은 인터페이스(1302)를 도시한 도면이다. UE(402)는 사용자가 소정의 스케줄로 통신하고, 디바이스가 이동 또는 고정인지를 표시하는 것 등을 하도록 디바이스를 구성하게 하는 GUI(1302)를 지원할 수 있다. 다른 작업들에서, N-API를 통해 U-SCEF(902)와 통신하는 애플리케이션은 GUI 기반 애플리케이션일 수 있다. GUI는 U-SCEF(902)에 구성 정보를 통과시키기 위해 위에 설명된 N-API를 사용할 수 있다. 인터페이스(1302)는 아래에 설명되는 도 14c-d에 도시한 것들과 같은 디스플레이들을 사용하여 발생될 수 있다는 것이 이해될 것이다.

추가의 배경 자료

네트워크 기능 가상화(NFV)는 많은 네트워크 장비 유형들을 데이터 센터들, 네트워크 노드들 내에 그리고 최종 사용자 구내들 내에 배치될 수 있는 산업 표준 높은 볼륨 서버들, 스위치들 및 스토리지 상으로 통합하기 위해 표준 IT 가상화 기술을 진화시킴으로써 네트워크 운영자들이 네트워크들을 구축하는 방식을 변환하는 것을 목적으로 한다. 그것은 산업 표준 서버 하드웨어의 범위 상에서 실행할 수 있고, 새로운 장비를 설치할 필요 없이, 요구된 대로 네트워크 내의 다양한 위치들로 이동되고, 또는 그 안에서 인스턴스화될수 있는 소프트웨어에서의 네트워크 기능들(예를 들어, 이동성 관리, 세션 관리, QoS)의 구현을 포함한다. NFV는 이동 및 고정 네트워크들 내의 어떤 데이터 평면 패킷 처리 및 제어 평면 기능에 적용가능하다. 잠재적인 예들은 다음을 포함할 수 있다:

● 스위칭 요소들: BNG, CG-NAT, 라우터들.

● 이동 네트워크 노드들: HLR/HSS, MME, SGSN, GGSN/PDN-GW, RNC, eNodeB.

● 가상화된 홈 환경들을 생성하기 위해 홈 라우터들 및 셋톱 박스들 내에 포함된 기능들.

● 집중된 기능 및 네트워크-와이드 기능: AAA 서버들, 정책 제어 및 과금 플랫폼들.

● 애플리케이션-레벨 최적화: CDN들, 캐시 서버들, 로드 밸런서들, 애플리케이션 가속기들.

● 보안 기능들: 방화벽들, 바이러스 스캐너들, 침입 검출 시스템들, 스팸 방지.

NFV의 애플리케이션은 원거리 통신 산업 전망의 극적인 변화에 기여하는 네트워크 운영자들에 많은 이점들을 가져다 준다. NFV는 다음의 이점들을 가져다 줄 수 있었다:

● 장비를 통합하고 IT 산업의 규모의 경제성들을 이용하는 것을 통해 감소된 장비 비용들 및 감소된 전력 소비.

● 전형적인 네트워크 운영자 혁신 사이클을 최소화함으로써 제품의 증가된 출시 속도.

● 동일한 인프라스트럭처 상에서의 제조, 테스트 및 기준 설비들을 실행하는 가능성은 훨씬 더 효율적인 테스트 및 통합을 제공하고, 제품의 개발 비용들 및 출시 시간을 줄인다.

● 지리 또는 고객 설정들에 기초한 타깃된 서비스 도입이 가능한다. 서비스들은 요구되는 대로 빠르게 스케일 업/다운될 수 있다.

● 광범위하게 다양한 에코 시스템들을 가능하게 하고 개방성을 고무한다.

● 실제 트래픽/이동성 패턴들 및 서비스 요구에 기초하여 거의 실시간으로 네트워크 구성 및/또는 토폴로지를 최적화한다.

● 멀티 테넌시를 지원함으로써 네트워크 운영자들이 관리 도메인들의 적절한 보안 격리로 동일한 하드웨어 상에 모두 공존하는, 다수 사용자들, 애플리케이션들 또는 내부 시스템들 또는 다른 네트워크 운영자들을 위한 맞춤형 서비스들 및 접속을 제공하게 한다.

● 작업 부하 통합 및 위치 최적화뿐만 아니라, 표준 서버들 및 스토리지 내의 전력 관리 특징들을 이용함으로써 에너지 소비를 줄인다.

유럽 통신 표준 기구(ETSI)는 일부 백서들을 공개하고, 판매자들 및 운영자들이 NFV를 구현하는 것을 고려하는 참조들로서 기능하는 NFV에 대한 표준 용어 정의들 및 사용 경우들을 포함하는, 여러가지 보다 면밀한 자료들을 만들기 위해 규격 그룹 "네트워크 기능들 가상화"를 형성하였다.

ETSI GS NFV 002, 네트워크 기능들 가상화(NFV); 구조적 프레임워크는 NFV 개념들을 이동 코어 네트워크에 적용하기 위한 구조적 프레임워크를 확립하는 ETSI 공개이다.

도 15는 ETSI GS NFV 002로부터 복사된 VNF들 및 네스트된 포워딩 그래프들을 갖는 예시적인 단-대-단 네트워크 서비스이다. 이 도면은 가상화된 네트워크 기능 포워딩 그래프(VNF-FG)의 개념을 도시한다. VNF-GW는 VNF의 세트가 서비스를 제공하기 위해 어떻게 접속되는지를 설명한다.

차세대 이동 네트워크(NGMN) 얼라이언스, "네트워크 슬라이싱 개념의 설명"에서 설명된 것과 같은 네트워크 슬라이싱은 이동 운영자의 네트워크, 백홀과 코어 네트워크 둘 다의 고정된 부분을 가로질러 에어 인터페이스 뒤의 다중 '가상' 네트워크들을 지원하기 위해 이동 네트워크 운영자들에 의해 사용될 수 있는 메커니즘이다. 이것은 단일 RAN을 가로질러 실행하는 상이한 RAN들 또는 상이한 서비스 유형들을 지원하기 위해 다중 가상 네트워크들 내로 네트워크를 "슬라이싱"하는 것을 포함한다. 네트워크 슬라이싱은 운영자가 예를 들어 기능성, 성능 및 격리의 영역들에서, 다양한 요건들을 요구하는, 상이한 시장 시나리오들에 대한 최적화된 해결책들을 제공하기 위해 맞춤화된 네트워크들을 생성하게 한다. 도 16은 네트워크 슬라이싱의 개념적 아키텍처를 도시한다. 상이한 색들이 상이한 네트워크 슬라이스 인스턴스들 또는 서브-네트워크 슬라이스 인스턴스들을 표시하기 위해 사용된다.

3GPP는 5G 네트워크를 설계하고 5G 네트워크에 잘 맞는 네트워크 슬라이싱 기술을 통합하는 것을 고려한다. 5G 사용 경우들(예를 들어, 대량 IoT, 중요한 통신들, 및 향상된 이동 브로드밴드)은 매우 다양하고 때때로 극한 요건들을 요구하기 때문이다. 현재의 아키텍처는 스마트폰들, OTT 콘텐트, 피처폰들, 데이터 카드들, 및 내장된 M2M 디바이스들로부터의 이동 트래픽과 같은 다양한 서비스들을 수용하기 위해 비교적 모놀리식한 네트워크 및 트랜스포트 프레임워크를 이용한다. 현재의 아키텍처는 각각이 그 자신의 특정 세트의 성능, 스케일가능성 및 가용성 요건들을 가질 때 더 넓은 범위의 업무 필요를 효율적으로 지원하기에 충분한 신축성 및 스케일가능성이 없는 것으로 예상된다. 또한, 새로운 네트워크 서비스들의 도입은 보다 효율적으로 되어야 한다. 그럼에도 불구하고, 여러가지 사용 경우들이 동일한 운영자 네트워크에서 동시에 활성으로 되고, 그러므로 5G 네트워크의 고도의 신축성 및 스케일가능성이 필요한 것으로 예상된다.

네트워크 슬라이싱은 운영자가 예를 들어 기능성, 성능 및 격리의 영역들에서, 다양한 요건들을 요구하는, 상이한 시장 시나리오들에 대한 최적화된 해결책들을 제공하기 위해 맞춤화된 네트워크들을 생성하게 한다. 그러나, 미래의 5G 네트워크에서 네트워크 슬라이싱을 지원하는 데는 몇가지 도전들 및 과제들이 있다:

● 네트워크 슬라이스 인스턴스들 간에 격리/분리를 어떻게 달성하고 어떤 레벨들 및 유형들의 격리/분리가 요구될 것인지;

● 리소스 및 네트워크 기능 공유가 네트워크 슬라이스 인스턴스들 사이에서 어떻게 사용되고 어떤 유형이 사용될 수 있는지;

● UE가 하나의 운영자의 하나 이상의 특정한 네트워크 슬라이스 인스턴스들로부터 서비스들을 어떻게 동시에 획득하게 하는지;

● 네트워크 슬라이싱(예를 들어, 네트워크 슬라이스 생성/구성, 수정, 삭제)에 관해 어떤 것이 3GPP 범위 내에 있는지;

● 어떤 네트워크 기능들이 특정한 네트워크 슬라이스 인스턴스 내에 포함될 수 있는지, 및 어떤 네트워크 기능들이 네트워크 슬라이스들과 독립인지;

● UE에 대한 특정한 네트워크 슬라이스의 선택의 절차(들);

● 네트워크 슬라이싱 로밍 시나리오들을 어떻게 지원하는지;

● 운영자들이 유사한 네트워크 특성들을 요구하는 다수의 제3자들(예를 들어, 기업들, 서비스 제공자들, 콘텐트 제공자들 등)을 효율적으로 지원하기 위해 네트워크 슬라이싱 개념을 어떻게 사용하게 하는지.

보다 상세한 것들(즉, 과제들, 문제들 및 가능한 해결책들)은 3GPP가 5G 네트워크 아키텍처 내의 네트워크 슬라이싱에 어떻게 적용하는 지에 관한 차세대 시스템을 위한 아키텍처에 관한 연구인, 3GPP TR 23.799에서 발견될 수 있다.

UE가 하나의 네트워크 운영자의 다수의 네트워크 슬라이스들로부터 서비스들을 동시에 획득하게 하기 위해, 단일 세트의 제어 평면 기능들이 도 17에 도시한 것과 같은 다수의 코어 네트워크 인스턴스들에 걸쳐 공유된다. 이 도면은 다수의 네트워크 슬라이스들에의 다수의 접속들의 지원을 위한 해결책의 업데이트인 3GPP S2-162259로부터 복사되었다.

코어 네트워크 인스턴스는 단일 세트의 제어 평면 기능들 및 단일 세트의 사용자 평면 기능들로 이루어진다. 또한, 코어 네트워크 인스턴스는 동일한 UE 유형에 속하는 UE들에 전용된다. UE 유형을 식별하는 것은 특정 파라미터, 예를 들어, UE 사용 유형, 및/또는 UE의 가입으로부터의 정보를 사용함으로써 행해진다. 코어 네트워크 인스턴스 내의 한 세트의 사용자 평면 기능들은 UE에 특정 서비스를 제공하고 특정 서비스의 사용자 평면 데이터를 트랜스포트하는 것을 담당한다. 예를 들어, 코어 네트워크 인스턴스#1 내의 한 세트의 사용자 평면 기능들은 향상된 이동 브로드밴드 서비스를 UE에 제공하는 반면, 코어 네트워크 인스턴스#2 내의 또 하나의 세트의 사용자 평면 기능들은 향상된 중요한 통신 서비스를 UE에 제공한다. UE가 먼저 운영자의 네트워크에 접속할 때, UE 사용 유형에 맞은 디폴트 코어 네트워크 인스턴스가 UE에 할당된다. 각각의 UE는 상이한 코어 네트워크 인스턴스들에서 동시에 가용한 상이한 세트들의 사용자 평면 기능에의 다수의 사용자 평면 접속들을 가질 수 있다. 제어 평면 기능들은 네트워크 슬라이스들에 걸쳐 공유될 수 있다.

코어 네트워크 선택 기능(CNSF)은 다음을 담당한다:

● UE의 가입 및 특정 파라미터, 예를 들어, UE 사용 유형을 고려함으로써 UE를 수용하기 위해 어떤 코어 네트워크 인스턴스를 선택하는 것.

● 기지국이 통신하여야 하는 선택된 코어 네트워크 인스턴스 내의 어떤 제어 평면 기능들을 선택하는 것. 제어 평면 기능들의 이 선택은 특정 파라미터, 예를 들어, UE 사용 유형을 사용함으로써 행해진다.

● 기지국이 상이한 서비스들의 사용자 평면 데이터를 트랜스포트하기 위해 접속을 확립하여야 하는 어떤 세트의 사용자 평면 기능들을 선택하는 것. 사용자 평면 기능의 이 선택은 특정한 파라미터, 예를 들어, UE 사용 유형 및 서비스 유형을 사용함으로써 행해진다.

네트워크 기능들의 상호접속을 가능하게 하기 위해, 상호접속 & 라우팅 기능(IRF) 2058이 차세대 시스템을 위한 아키텍처에 관한 연구인, 3GPP TR 23.799에서 제안된다. 도 18 및 도 19는 각각 비로밍 및 로밍 시나리오들을 위한 IRF 2058의 기준 모델들을 도시한다. IRF 2058의 기능들은 다음을 포함한다:

● UE의 아이덴티티와 UE에 대해 활성 세션을 갖는 각각의 서빙 NF의 인터페이스 계층 아이덴티티(예를 들어, 인스턴스 번호) 간의 바인딩을 저장한다. 직접 IRF 2058과 인터페이스하지 않는 NF들에 대해, 예들 들어, 로밍 시나리오에서, IRF 2058은 그들 NF들이 도달가능한 원격-PLMN의 IRF 2058의 아이덴티티를 저장한다.

● 서빙 NF의 아이덴티티가 예를 들어, UE 이동성, 로드 리밸런싱(즉, 가상 머신들의 스케일-인 또는 스케일-아웃) 또는 복원 이유들로 인해, 주어진 UE에 대해 변화할 때 바인딩 리포지토리를 업데이트한다.

● (메시지가 송신되는) UE의 아이덴티티 및 목적지 NF를 결정하기 위해 메시지 헤더를 조사한다. UE의 아이덴티티에 대해, 목적지 NF의 인터페이스 계층 아이덴티티(예를 들어, 인스턴스 번호) 또는 원격 IRF 2058의 아이덴티티를 결정하기 위해 내부 바인딩 리포지토리를 찾는다. 그에 따라 메시지를 라우트한다.

● 운영자의 구성에 기초하여 메시지의 허가를 선택적으로 수행하는데, 예를 들어, 운영자의 구성이 NF1이 ("UE의 APN-AMBR의 변화"와 같은) 소정의 메시지를 NF4를 향해 송신하는 것을 금지한다면 IRF 2058은 대응하는 메시지를 거절한다. 오버로드 제어, 예를 들어, 그것의 로드/오버로드 조건에 기초하여 주어진 NF에 송신된 메시지들의 페이싱을 수행함으로써 시그널링 스톰 중에 NF들을 선택적으로 보호한다.

각각의 NF는 그 자신의 PLMN 내의 주어진 기준 점을 통해 IRF 2058과 인터페이스한다. NF들은 서로 직접 인터페이스하지 않지만 IRF 2058을 통해 서로 통신할 수 있다(즉, 요구 또는 응답 메시지를 송신할 수 있다). 그러므로, 요구될 때, 이 모델은 임의의 NF가 경로 내의 기타 관련되지 않은 네트워크 기능들을 관련시키지 않고서 기타 NF와 직접 통신하게 하는데, 예를 들어, NF1은 NF2의 관련성이 필요하지 않다면 NF2를 관련시키지 않고 IRF 2058을 통해 메시지를 NF3에 송신할 수 있다.

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

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

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

도 14a는 하나 이상의 개시된 실시예가 구현될 수 있는 예시적인 머신 대 머신(M2M), 사물 인터넷(IoT), 또는 사물 웹(WoT) 통신 시스템(10)의 도면이다. 일반적으로, M2M 기술들은 IoT/WoT에 대한 빌딩 블록들을 제공하고, 임의의 M2M 디바이스, M2M 게이트웨이, M2M 서버, 또는 M2M 서비스 플랫폼은 IoT/WoT 서비스 계층뿐만 아니라 IoT/WoT의 소자 또는 노드 등일 수 있다. 통신 시스템(10)은 개시된 실시예들의 기능성을 구현하기 위해 사용될 수 있고 SCEF(102), PCRF(102), PCEF(206), SPR(204), AS(202), MME(304), HSS(302), UE(402), S-GW(406), P-GW(404), CSE(502), CSF, U-SCEF(902), N-API(904), S-API(906), EPC(908), EPC 인터워킹 서비스(1002)와 같은 기능성 및 논리적 엔티티들, 및 GUI(1302)와 같은 GUI들을 발생하는 논리적 엔티티들을 포함할 수 있다.

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

도 14a에 도시한 바와 같이, 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, 블루투스), 직접 무선 링크, 및 유선을 포함하는 다양한 네트워크들을 통해 통신할 수 있다.

예시적인 M2M 단말 디바이스들(18)은 태블릿들, 스마트폰들, 의료 디바이스들, 온도 및 날씨 모니터들, 커넥티트 카들, 스마트 미터들, 게임 콘솔들, 개인 휴대 단말들, 헬스 및 휘트니스 모니터들, 조명 기기들, 온도 조정 장치들, 기기들, 차고 문들 및 다른 액추에이터-기반 디바이스들, 안전 디바이스들, 및 스마트 아울렛들을 포함하지만, 이들로 제한되지 않는다.

도 14b를 참조하면, 필드 도메인 내의 도시된 M2M 서비스 계층(22)은 M2M 애플리케이션(20), M2M 게이트웨이 디바이스들(14), 및 M2M 단말 디바이스들(18) 및 통신 네트워크(12)에 서비스들을 제공한다. 통신 네트워크(12)는 개시된 실시예들의 기능성을 구현하기 위해 사용될 수 있고 SCEF(102), PCRF(102), PCEF(206), SPR(204), AS(202), MME(304), HSS(302), UE(402), S-GW(406), P-GW(404), CSE(502), CSF, U-SCEF(902), N-API(904), S-API(906), EPC(908), EPC 인터워킹 서비스(1002)와 같은 기능성 및 논리적 엔티티들, 및 GUI(1302)와 같은 GUI들을 발생하는 논리적 엔티티들을 포함할 수 있다. M2M 서비스 계층(22)은 예를 들어 아래에 설명되는 도 14c 및 14d에 도시된 디바이스들을 포함하는, 하나 이상의 서버, 컴퓨터, 디바이스, 가상 머신(예를 들어, 클라우드/스토리지 팜들 등)에 의해 구현될 수 있다. 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')은 서버들, 컴퓨터들, 가상 머신들(예를 들어, 클라우드 컴퓨팅/저장 팜들 등) 등을 포함할 수 있는, 네트워크의 하나 이상의 노드에 의해 구현될 수 있다.

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

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

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

한 실시예에서, SCEF(102), PCRF(102), PCEF(206), SPR(204), AS(202), MME(304), HSS(302), UE(402), S-GW(406), P-GW(404), CSE(502), CSF, U-SCEF(902), N-API(904), S-API(906), EPC(908), EPC 인터워킹 서비스(1002)와 같은 논리적 엔티티, 및 GUI(1302)와 같은 GUI들을 발생하는 논리적 엔티티들은 도 14b에 도시한 바와 같이, M2M 서버, M2M 게이트웨이, 또는 M2M 디바이스와 같은 M2M 노드에 의해 호스트된 M2M 서비스 계층 인스턴스 내에 호스트될 수 있다. 예를 들어, SCEF(102), PCRF(102), PCEF(206), SPR(204), AS(202), MME(304), HSS(302), UE(402), S-GW(406), P-GW(404), CSE(502), CSF, U-SCEF(902), N-API(904), S-API(906), EPC(908), EPC 인터워킹 서비스(1002)와 같은 논리적 엔티티들, 및 GUI(1302)와 같은 GUI들을 발생하는 논리적 엔티티들은 M2M 서비스 계층 인스턴스 내에 또는 기존의 서비스 능력 내의 서브-기능으로서 개별적인 서비스 능력을 포함할 수 있다.

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

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

또한, SCEF(102), PCRF(102), PCEF(206), SPR(204), AS(202), MME(304), HSS(302), UE(402), S-GW(406), P-GW(404), CSE(502), CSF, U-SCEF(902), N-API(904), S-API(906), EPC(908), EPC 인터워킹 서비스(1002)와 같은 논리적 엔티티들, 및 GUI(1302)와 같은 GUI들을 발생하는 논리적 엔티티들은 본원의 서비스들에 액세스하기 위해 서비스 지향 아키텍처(SOA) 및/또는 리소스 지향 아키텍처(ROA)를 사용하는 M2M 네트워크의 부분으로서 구현될 수 있다.

도 14c는 M2M 디바이스(18), M2M 게이트웨이(14), M2M 서버 등과 같은 M2M 네트워크 노드(30)의 예시적인 하드웨어/소프트웨어 아키텍처의 블록도이다. 노드(30)는 SCEF(102), PCRF(102), PCEF(206), SPR(204), AS(202), MME(304), HSS(302), UE(402), S-GW(406), P-GW(404), CSE(502), CSF, U-SCEF(902), N-API(904), S-API(906), EPC(908), EPC 인터워킹 서비스(1002)와 같은 논리적 엔티티들, 및 GUI(1302)와 같은 GUI들을 발생하는 논리적 엔티티들을 실행하거나 포함할 수 있다.

디바이스(30)는 도 14a-b에 도시한 것과 같은 M2M 네트워크의 일부 또는 비-M2M 네트워크의 일부일 수 있다. 도 14c에 도시한 바와 같이, M2M 노드(30)는 프로세서(32), 비이동식 메모리(44), 이동식 메모리(46), 스피커/마이크로폰(38), 키패드(40), 디스플레이, 터치패드, 및/또는 표시기들(42), 전원(48), 전지구 위치파악 시스템(GPS) 칩셋(50), 및 다른 주변 장치들(52)을 포함할 수 있다. 노드(30)는 또한 송수신기(34) 및 송신/수신 요소(36)와 같은 통신 회로를 포함할 수 있다. M2M 노드(30)는 실시예와 일치하게 남으면서 전술한 요소들의 임의의 부조합을 포함할 수 있다는 것을 알 것이다. 이 노드는 여기서 설명된 SMSF 기능성을 구현하는 노드일 수 있다.

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

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

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

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

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

프로세서(32)는 비이동식 메모리(44) 및/또는 이동식 메모리(46)와 같은, 임의 유형의 적합한 메모리로부터의 정보에 액세스하고, 그 안에 데이터를 저장할 수 있다. 예를 들어, 프로세서(32)는 위에 설명된 바와 같이, 그것의 메모리 내에 세션 콘텍스트를 저장할 수 있다. 비이동식 메모리(44)는 랜덤 액세스 메모리(RAM), 리드 온리 메모리(ROM), 하드 디스크, 또는 기타 유형의 메모리 저장 디바이스를 포함할 수 있다. 이동식 메모리(46)는 가입자 식별 모듈(SIM) 카드, 메모리 스틱, 시큐어 디지털(SD) 메모리 카드 등을 포함할 수 있다. 다른 실시예들에서, 프로세서(32)는 서버 또는 홈 컴퓨터 상에 있는 것과 같이, M2M 노드(30) 상에 물리적으로 배치되지 않는 메모리로부터의 정보에 액세스하고, 그 안에 데이터를 저장할 수 있다. 프로세서(32)는 M2M 서비스 계층 세션 이동 또는 공유의 상태를 반영하고 사용자로부터 입력을 획득하고 또는 노드의 세션 이동 또는 공유 능력들 또는 설정들에 관한 정보를 사용자에게 디스플레이하기 위해 디스플레이 또는 표시기들(42) 상의 조명 패턴들, 영상들, 또는 색들을 제어하도록 구성될 수 있다. 또 하나의 예에서, 디스플레이는 세션 상태에 관해 정보를 보일 수 있다. 현재의 개시내용은 oneM2M 실시예에서의 RESTful 사용자/애플리케이션 API를 정의한다. 디스플레이 상에 보일 수 있는 그래픽 사용자 인터페이스는 여기에 설명된 기반 서비스 계층 세션 기능성을 통해, 사용자가 E2E 세션, 또는 그것의 이동 또는 공유를 상호작용하여 확립하고 관리하게 하기 위해 API의 상부 상에 층이 질 수 있다.

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

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

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

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

도 14d는 M2M 서버, 게이트웨이, 디바이스, 또는 다른 노드와 같은, M2M 네트워크의 하나 이상의 노드를 구현하기 위해 사용될 수 있는, 예시적인 컴퓨팅 시스템(90)의 블록도이다. 컴퓨팅 시스템(90)은 컴퓨터 또는 서버를 포함할 수 있고 소프트웨어의 형태, 이러한 소프트웨어가 어디에 저장되거나 액세스되든지, 또는 어떤 수단이든지 간에 주로 컴퓨터 판독가능 명령어들에 의해 제어될 수 있다. 컴퓨팅 시스템(90)은 SCEF(102), PCRF(102), PCEF(206), SPR(204), AS(202), MME(304), HSS(302), UE(402), S-GW(406), P-GW(404), CSE(502), CSF, U-SCEF(902), N-API(904), S-API(906), EPC(908), EPC 인터워킹 서비스(1002)와 같은 논리적 엔티티들, 및 GUI(1302)와 같은 GUI들을 발생하는 논리적 엔티티들을 실행하거나 포함할 수 있다. 컴퓨팅 시스템(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)은 컴퓨터 시스템(90)이 네트워크의 다른 노드들과 통신하게 하기 위해, 컴퓨팅 시스템(90)을 도 14a 및 도 14b의 네트워크(12)와 같은, 외부 통신 인터페이스에 접속하기 위해 사용될 수 있는, 예를 들어 네트워크 어댑터(97)와 같은 통신 회로를 포함할 수 있다.

사용자 장비(UE)는 통신하기 위해 최종 사용자에 의해 사용되는 임의의 디바이스일 수 있다. 그것은 휴대용 전화, 이동 브로드밴드 어댑터가 장치된 랩탑 컴퓨터, 또는 기타 디바이스일 수 있다. 예를 들어, UE는 도 14a-b의 M2M 단말 디바이스(18) 또는 도 14c의 디바이스(30)로서 구현될 수 있다.

여기에 설명된 시스템들, 방법들 및 처리들 중 어느 것 또는 모두가 명령어들이 예를 들어 M2M 서버, 게이트웨이, 디바이스 등을 포함하는, M2M 네트워크의 노드와 같은 머신에 의해 실행될 때 여기에 설명된 시스템들, 방법들, 처리들을 수행 및/또는 구현하는 컴퓨터 판독가능 저장 매체 상에 저장된 컴퓨터 실행가능 명령어들(예를 들어, 프로그램 코드)의 형태로 실시될 수 있다는 것이 이해된다. 구체적으로, 게이트웨이, UE, UE/GW, 또는 이동 코어 네트워크의 노드들 중 어느 것, 서비스 계층 또는 네트워크 애플리케이션 제공자의 동작들을 포함하는, 위에 설명된 단계들, 동작들 또는 기능들 중 어느 것이 이러한 컴퓨터 실행가능 명령어들의 형태로 구현될 수 있다. SCEF(102), PCRF(102), PCEF(206), SPR(204), AS(202), MME(304), HSS(302), UE(402), S-GW(406), P-GW(404), CSE(502), CSF, U-SCEF(902), N-API(904), S-API(906), EPC(908), EPC 인터워킹 서비스(1002)와 같은 논리적 엔티티들, 및 GUI(1302)와 같은 GUI들을 발생하는 논리적 엔티티들은 컴퓨터 판독가능 저장 매체 상에 저장된 컴퓨터 실행가능 명령어들의 형태로 실시될 수 있다. 컴퓨터 판독가능 저장 매체는 정보의 저장을 위해 임의의 비일시적(즉, 실재적 또는 물리적) 방법 또는 기술로 구현된 휘발성과 비휘발성, 이동식과 비이동식 매체를 포함하지만, 이러한 컴퓨터 판독가능 저장 매체는 신호들을 포함하지 않는다. 컴퓨터 판독가능 저장 매체는 RAM, ROM, EEPROM, 플래시 메모리 또는 다른 메모리 기술, CD-ROM, 디지털 다기능 디스크들(DVD) 또는 다른 광학 디스크 저장 디바이스, 자기 카세트들, 자기 테이프, 자기 디스크 저장 또는 다른 자기 저장 디바이스들, 또는 원하는 정보를 저장하기 위해 사용될 수 있고 컴퓨터에 의해 액세스될 수 있는 기타 실재적 또는 물리적 매체를 포함할 수 있다.

도면에 도시된 것과 같은 본 개시내용의 주제의 양호한 실시예들을 설명하는데 있어서, 특정한 용어가 명료성을 위해 사용된다. 그러나, 청구된 주제는 그렇게 선택된 특정한 용어로 제한되는 것으로 의도되지 않고, 각각의 특정한 요소는 유사한 목적을 달성하기 위해 유사한 방식으로 동작하는 모든 기술적 등가물을 포함한다는 것을 이해할 것이다.

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

Claims (20)

1. 프로세서, 메모리, 및 통신 회로를 포함하는 사용자 장비(UE)로서, 상기 UE는 자신의 통신 회로를 통해 네트워크에 접속되고, 상기 UE는, 상기 UE의 상기 프로세서에 의해 실행될 때, 상기 UE로 하여금 동작들을 수행하게 하는 상기 UE의 상기 메모리 내에 저장된 컴퓨터 실행가능 명령어들을 더 포함하고, 상기 동작들은
   코어 네트워크 인터워킹 서비스에게 요구를 송신하는 동작 - 상기 요구는 상기 UE의 식별자를 포함하고, 상기 식별자는 상기 UE를 인증하기 위하여 상기 코어 네트워크 인터워킹 서비스에 의해 사용됨 -;
   원하는 스케줄, 상기 UE에 대한 이동성 정보, 또는 배터리 레벨 정보를 포함하는 메시지를 상기 코어 네트워크 인터워킹 서비스에게 송신하는 동작; 및
   상기 코어 네트워크 인터워킹 서비스로부터 응답을 수신하는 동작
   을 포함하는 UE.
2. 제1항에 있어서, 상기 원하는 스케줄, 상기 UE에 대한 이동성 정보, 또는 배터리 레벨 정보는 애플리케이션 또는 애플리케이션 프로그래밍 인터페이스 호출로부터 수신되는 UE.
3. 제2항에 있어서, 상기 애플리케이션은 AT 명령 또는 API 인터페이스를 사용하여 상기 원하는 스케줄, 상기 UE에 대한 이동성 정보, 또는 배터리 레벨 정보를 상기 UE에게 송신하는 UE.
4. 제2항에 있어서, 상기 응답으로부터의 정보는 상기 애플리케이션에 제공되는 UE.
5. 제4항에 있어서, 상기 UE는 AT 명령 또는 API 인터페이스를 사용하여 상기 응답으로부터의 상기 정보를 상기 애플리케이션에게 송신하는 UE.
6. 제2항에 있어서, 상기 원하는 스케줄은 상기 UE에서 다수의 애플리케이션으로부터의 입력을 반영하는 UE.
7. 제1항에 있어서, 상기 UE는 서비스 노출 기능을 포함하는 UE.
8. 제7항에 있어서, 상기 UE의 상기 서비스 노출 기능은 상기 코어 네트워크 인터워킹 서비스와 상호작용하는 UE.
9. 제1항에 있어서, 메시지는 상기 코어 네트워크 인터워킹 서비스에 대한 참조 번호를 포함하고 상기 코어 네트워크 인터워킹 서비스로부터 상기 UE로의 상기 응답은 상기 참조 번호를 포함하는 UE.
10. 제9항에 있어서, 상기 UE는 세션 관리 또는 이동성 관리 메시지 내 상기 코어 네트워크에 대한 상기 참조 번호를 제공하는 UE.
11. 제1항에 있어서, 상기 원하는 스케줄은 다운로드 크기, 업로드 크기, 또는 기한과 연관된 UE.
12. 제1항에 있어서, 상기 응답은 스케줄을 포함하는 UE.
13. 제12항에 있어서, 상기 스케줄은 시작 시간을 포함하는 UE.
14. 제12항에 있어서, 상기 UE는 상기 스케줄을 사용하여 통신하는 UE.
15. 제12항에 있어서, 상기 응답은 하나 이상의 이동성 관리 타이머 값을 포함하는 UE.
16. 제15항에 있어서, 상기 UE는 상기 하나 이상의 이동성 관리 타이머 값을 상기 코어 네트워크에게 송신하는 UE.
17. 제1항에 있어서, 상기 UE의 상기 식별자는 IP 주소 또는 외부 식별자인 UE.
18. 제1항에 있어서, 상기 이동성 정보는 고정 표시, 위치, 이동성 영역, 또는 속도 정보를 포함하는 UE.
19. 코어 네트워크 인터워킹 서비스를 호스트하는 네트워크 엔티티로서, 상기 네트워크 엔티티는 프로세서, 메모리, 및 통신 회로를 포함하고, 상기 네트워크 엔티티는 자신의 통신 회로를 통해 네트워크에 접속되고, 상기 네트워크 엔티티는 상기 네트워크 엔티티의 상기 프로세서에 의해 실행될 때, 상기 네트워크 엔티티로 하여금 동작들을 수행하게 하는 상기 네트워크 엔티티의 상기 메모리 내에 저장된 컴퓨터 실행가능 명령어들을 더 포함하고, 상기 동작들은
    UE로부터 요구를 수신하는 동작 - 상기 요구는 상기 UE의 식별자를 포함하고, 상기 식별자는 상기 UE를 인증하기 위하여 상기 코어 네트워크 인터워킹 서비스에 의해 사용됨 -;
    원하는 스케줄, 상기 UE에 대한 이동성 정보, 또는 배터리 레벨 정보를 포함하는 메시지를 상기 UE로부터 수신하는 동작; 및
    응답을 상기 UE에게 송신하는 동작
    을 포함하는 네트워크 엔티티.
20. 코어 네트워크 인터워킹 서비스를 위한 방법으로서,
    UE로부터 요구를 수신하는 단계 - 상기 요구는 상기 UE의 식별자를 포함하고, 상기 식별자는 상기 UE를 인증하기 위하여 상기 코어 네트워크 인터워킹 서비스에 의해 사용됨 -;
    원하는 스케줄, 상기 UE에 대한 이동성 정보, 또는 배터리 레벨 정보를 포함하는 메시지를 상기 UE로부터 수신하는 단계; 및
    응답을 상기 UE에게 송신하는 단계
    를 포함하는 방법.
    

Images