KR20170028952A - 복수의 트랜스포트 메커니즘을 지원하는 네트워크들을 위한 애플리케이션 데이터 전달 서비스 - Google Patents

Abstract

애플리케이션 데이터 전달 서비스(ADDS; Application Data Delivery Service)는, 디바이스 영역(예를 들어, M2M/MTC 디바이스 및 게이트웨이)과 네트워크 영역(예를 들어, AS 또는 SCS)에 존재하는 애플리케이션들 사이에서 애플리케이션 데이터 전송을 가능하게 한다. ADDS는, NAS, SMS, USSD, 및 사용자 평면 등의 기존의 3GPP 트랜스포트 메커니즘을 활용하고, 애플리케이션 데이터 특성, 애플리케이션/엔드 노드 특성 및 가용성, 가입 정보, 네트워크의 정책, (정체, 노드 가용성 등의) 네트워크 상태 등의 기준에 기초하여 애플리케이션 데이터를 전달하기 위한 트랜스포트 메커니즘을 선택하도록 구성된다.

Description

복수의 트랜스포트 메커니즘을 지원하는 네트워크들을 위한 애플리케이션 데이터 전달 서비스{APPLICATION DATA DELIVERY SERVICE FOR NETWORKS SUPPORTING MULTIPLE TRANSPORT MECHANISMS}

제3세대 파트너쉽 프로젝트(3GPP)는 다수의 통신 표준 개발 기구들을 통합하고, 그들 멤버들에게, 무선 액세스, 코어 트랜스포트 네트워크, 및 서비스 능력을 포함한, 셀룰러 통신 네트워크 기술들에 대한 명세를 개발하기 위한 환경을 제공한다. 3GPP 명세는 또한, 코어 네트워크로의 비-무선 액세스를 위한, 및 다른 네트워크들과의 상호연동을 위한 후크(hook)를 제공한다.

무선 통신을 위한 3GPP 코어 네트워크 아키텍쳐의 최근의 진보는 EPC(Evolved Packet Core)라 불린다. EPC는 3GPP에 의해 표준의 Release 8에서 처음 도입되었다. 이것은, 성능과 비용 관점에서 데이터 트래픽을 효율적으로 핸들링하기 위하여 "플랫 아키텍쳐(flat architecture)"를 갖도록 설계되었고, 트래픽을 핸들링하는 데 있어서 소수의 네트워크 노드가 관여된다. 프로토콜 변환도 역시 일반적으로 회피된다. ("사용자 평면"이라고도 하는) 사용자 데이터를 ("제어 평면"이라고도 하는) 시그널링으로부터 분리하는 것이 역시 결정되어, 네트워크 오퍼레이터들이 그들의 네트워크를 용이하게 크기조정 및 구성할 수 있게 해준다.

도 1은 E-UTRAN(LTE 액세스 네트워크)을 통해 EPC(102)에 접속된 사용자 장비(UE)(104)(예를 들어, 모바일 전화 또는 다른 무선 디바이스)를 나타내는 기본 아키텍쳐 도면이다. 진보된 NodeB(eNodeB)(106)는 LTE 무선통신을 위한 기지국이다. 이 도면에서, EPC는 4개의 네트워크 요소 : 서빙 게이트웨이(서빙 GW)(110), 패킷 데이터 네트워크 게이트웨이(PDN GW)(112), MME(114) 및 HSS(116)로 구성된다. EPC는 외부 네트워크(108)에 접속될 수 있다.

HSS(Home Subscriber Server)(116)는 사용자 관련 및 가입자 관련 정보를 포함하는 데이터베이스이다. 이것은 또한, 이동성 관리, 통화 및 세션 셋업, 사용자 인증 및 액세스 인가에서 지원 기능들을 제공한다.

게이트웨이(서빙 GW(110) 및 PDN GW(112))는 사용자 평면을 취급한다. 이들은 사용자 장비(UE)와 외부 네트워크 사이에서 IP 데이터 트래픽을 트랜스포트한다. 서빙 GW(110)는 무선 측과 EPC 사이의 상호 접속점이다. 그 이름에서 알 수 있듯이, 이 게이트웨이는 인입 및 송출 IP 패킷들을 라우팅함으로써 UE를 서비스한다. 이것은, 인트라-LTE 이동성(즉, eNodeB들 사이의 핸드오버의 경우)을 위한 및 LTE와 다른 3GPP 액세스 사이의 앵커 지점이다. 이것은, 다른 게이트웨이, 즉, PDN GW에 논리적으로 접속된다.

PDN GW(112)는, EPC와 인터넷 등의 외부 IP 네트워크 사이의 상호 접속점이다. 이들 네트워크들은 PDN(패킷 데이터 네트워크)이라고 불리며, 따라서 그 명칭이다. PDN GW는 패킷들을 PDN들에 및 PDN들로부터 라우팅한다. PDN GW는 또한, IP 주소/IP 프레픽스 할당(prefix allocation) 또는 정책 제어와 과금 등의, 다양한 기능을 수행한다. 3GPP는 이들 게이트웨이들을 독립적으로 명시하지만, 실제로 이들은 네트워크 벤더들에 의해 단일의 "박스"로 결합될 수 있다.

MME(Mobility Management Entity)(114)는 제어 평면을 취급한다. 이것은 E-UTRAN 액세스를 위한 이동성 및 보안과 관련된 시그널링을 처리한다. MME는 유휴 모드에서 UE들의 추적 및 페이징을 담당한다. 이것은 또한 NAS(Non-Access Stratum)의 종단 지점이다.

도 1에 도시된 바와 같이, UE(104)는 E-UTRAN을 이용하여 EPC(102)에 도달할 수 있지만, 이것이 지원되는 유일한 액세스 기술은 아니다. 3GPP는 복수의 액세스 기술의 지원과 이들 접속들 간의 핸드오버를 명시한다. 이 아이디어는 복수의 액세스 기술을 통해 다양한 IP-기반 서비스를 제공하는 고유한 코어 네트워크를 이용하여 컨버전스를 실현하는 것이다. 기존의 3GPP 무선 액세스 네트워크들이 지원된다. 3GPP 명세는 E-UTRAN(LTE 및 LTE-Advanced), GERAN(GSM/GPRS의 무선 액세스 네트워크) 및 UTRAN(UMTS-기반 기술들 WCDMA 및 HSPA의 무선 액세스 네트워크) 사이에서 상호연동이 어떻게 달성되는지를 정의한다.

이 아키텍쳐는 또한 비-3GPP 기술이 UE와 EPC를 상호접속하는 것을 허용한다. 비-3GPP란, 이러한 액세스들이 3GPP에서 규정되지 않았다는 것을 의미한다. 이러한 기술들에는, 예를 들어, WiMAX, cdma2000®, WLAN 또는 고정 네트워크가 포함된다. 비-3GPP 액세스는 "신뢰할 수 있는 것" 및 "신뢰할 수 없는 것"의 두 범주로 나누어질 수 있다. 신뢰할 수 있는 비-3GPP 액세스는 EPC와 직접 상호작용할 수 있다. 신뢰할 수 없는 비-3GPP 액세스는 ePDG(Evolved Packet Data Gateway)(미도시)라고 불리는 네트워크 엔티티를 통해 EPC와 상호작용한다. ePDG의 주요 역할은, 신뢰할 수 없는 비-3GPP 액세스를 통한 UE와의 접속에 대한 IPsec 터널링과 같은 보안 메커니즘을 제공하는 것이다. 3GPP는 어느 비-3GPP 기술이 신뢰될 수 있는 것으로 또는 신뢰될 수 없는 것으로 간주되어야 하는지를 명시하지 않는다. 이 결정은 오퍼레이터에 의해 이루어진다.

도 1에 나타낸 3GPP 네트워크 아키텍쳐는 원래 인간에 의해 작동되는 디바이스들 간의 통신을 가능하게 하도록 설계되었다. 예를 들어, 3GPP 네트워크는, 인터넷 등의 패킷 교환형 네트워크와 GSM(Global System for Mobile Communications) 네트워크 등의 회선 교환형 네트워크로의 액세스를 스마트폰에 제공하는 데 매우 적합하다. 3GPP 네트워크는, 스마트 계측, 홈 오토메이션, eHealth, 소비자 제품, 차량 관리 등을 수반한 통신 등의, 머신 또는 디바이스들이 네트워크를 통해 서로 통신하는 머신 타입 통신(MTC)이라고도 하는 소위 M2M(Machine-to-Machine) 통신 처리에 최적화된 방식으로 원래 설계되지는 않았다.

3GPP 명세의 Release 11(R11)에서, 3GPP는, 머신 타입 통신/머신-대-머신 통신을 위한 UMTS 코어 네트워크의 상호연동 능력을 강화시켰다. 상호연동이란, 정보 교환, 디바이스 제어 또는 디바이스 모니터링 또는 디바이스와의 통신을 목적으로 코어 네트워크에 인터페이싱하는 서버 또는 애플리케이션을 말한다. 도 2는 TS 23.682 V11.5.0의 3GPP에 제시된 MTC 아키텍쳐를 도시한다.

도 2에 도시된 바와 같이, 서비스 능력 서버(SCS)(212)는, 코어 네트워크, 디바이스, 및 애플리케이션들에 서비스를 제공할 수 있다. SCS는, M2M 서버, MTC 서버, 서비스 능력 계층 또는 CSE(Common Services Entity)라고도 할 수 있다. SCS(212)는 HPLMN(home public land mobile network)의 오퍼레이터 또는 MTC 서비스 제공자에 의해 제어될 수 있다. SCS는 오퍼레이터 영역 내부 또는 외부에 배치될 수 있다. SCS가 오퍼레이터 영역 내부에 배치된다면, SCS는 내부 네트워크 기능일 수 있고 오퍼레이터에 의해 제어될 수 있다. SCS가 오퍼레이터 영역 외부에 배치된다면, SCS는 MTC 서비스 제공자에 의해 제어될 수 있다.

SCS는 Tsp 기준점(즉, 인터페이스)을 통해 머신 타입 통신(MTC) 상호연동 기능(MTC-IWF)(210)과 통신할 수 있다. Tsp 기준점은 코어 네트워크와의 상호연동에 이용되는 인터페이스의 예이다.

도 2에 더 도시된 바와 같이, 기준점(즉, 인터페이스) Tsms(202)는 단문 서비스(SMS) 서비스 센터(SMS-SC)(204)를 단문 엔티티(SME)(206)에 접속할 수 있다. Tsms 기준점은 코어 네트워크와의 상호연동에 이용되는 인터페이스의 또 다른 예이다. SMS-SC(204)는 T4 기준점을 통해 MTC-IWF와 통신한다.

도 2에 역시 도시된 바와 같이, SCS(212)는 사용자 장비 MTC(UE MTC) 애플리케이션(216), (예를 들어, 경계(218)에 의해 정의된) HPLMN 내의 MTC-IWF(210) 또는 디바이스 트리거링을 위한 SMS-SC(204)와 통신하기 위해 3GPP 네트워크에 접속할 수 있는 엔티티일 수 있다. SCS(212)는 하나 이상의 애플리케이션 서버 MTC(AS MTC) 애플리케이션들에 의한 이용을 위한 능력들을 제공할 수 있다.

UE는, 무선 액세스 네트워크(RAN)(219)를 포함하는 공중 육상 이동 네트워크(PLMN; public land mobile network)를 통해 SCS(들) 및/또는 다른 MTC UE(들)와 통신할 수 있다. MTC UE(214)는 하나 이상의 MTC 애플리케이션(216)을 호스팅할 수 있다. MTC 애플리케이션은 또한 하나 이상의 AS(220/222)에서 호스팅될 수도 있다. MTC 애플리케이션(216)은, SCS(212), AS MTC 애플리케이션, 또는 다른 UE MTC 애플리케이션과 상호작용할 수 있는 MTC 통신 엔드포인트일 수 있다.

애플리케이션 서버(AS)(220/222)는 또한 하나 이상의 MTC 애플리케이션을 호스팅할 수 있다. AS는 SCS(들)(212) 또는 GGSN/P-GW(224)와 인터페이스할 수 있다. AS 상의 MTC 애플리케이션은, SCS, UE MTC 애플리케이션, 또는 다른 MTC 애플리케이션과 상호작용할 수 있다.

MTC 상호연동 기능(MTC-IWF)(210)은 내부 PLMN 토폴로지를 SCS(212)로부터 은닉할 수 있다. MTC-IWF는, PLMN에서 MTC 기능(예를 들어, MTC UE 트리거링)을 지원하기 위해 자신과 SCS 사이에서 (예를 들어, Tsp 기준점(208)을 통해) 이용되는 시그널링 프로토콜을 중계 및/또는 변환할 수 있다. 예를 들어, SCS는 MTC-IWF가 MTC 디바이스에 트리거를 전송할 것을 요청할 수 있다. MTC-IWF는 SMS를 통해 MTC 디바이스(214)에 MTC 트리거를 전달할 수 있다. MTC 디바이스(216)는 트리거에 기초하여 SCS(212)에 응답할 수 있다. MTC 디바이스(216)는 예를 들어 센서 판독치로 응답할 수 있다. MTC 디바이스(216)가 SCS(212)에 응답할 때, MTC 디바이스는 패킷 데이터 네트워크(PDN)/패킷 데이터 프로토콜(PDP) 접속을 이용하여 SCS(212)와 통신할 수 있다. MTC 디바이스는 IP 접속을 이용하여 SCS에 접속할 수 있다.

MTC-IWF(210)는 SCS가 3GPP 네트워크와 통신을 확립하기 전에 SCS(212)를 인가할 수 있다. 예를 들어, SCS(212)가 Tsp 기준점에 대해 트리거 요청을 하면, MTC-IWF(210)는 SCS가 트리거 요청을 전송하도록 인가되었는지, 및 SCS가 트리거 제출의 할당량 또는 레이트를 초과하지 않았는지를 체크할 수 있다.

도 2에 더 도시된 바와 같이, 모바일 스위칭 센터(MSC)(238)는 GSM/CDMA에 대한 1차 서비스 전달 노드이며, 음성 통화 및 SMS뿐만 아니라 다른 서비스들(전화 회의, FAX 및 회선 교환형 데이터)의 라우팅을 담당한다. MSC는 종단간 접속을 셋업 및 해제하고, 통화 도중 이동성 및 핸드오버 요구를 처리하며, 과금 및 실시간 선불 계정 모니터링을 담당한다.

서빙 GPRS(general packet radio service) 지원 노드(SGSN)(234)는 자신의 지리적 서비스 영역 내의 모바일 디바이스들로부터의 및 모바일 디바이스들로의 데이터 패킷의 전달을 담당한다. 그 직무로서는, 패킷 라우팅 및 전송, 이동성 관리(접속/분리 및 위치 관리), 논리 링크 관리, 인증 및 과금 기능이 포함된다. SGSN의 위치 등록기는 등록된 모든 GPRS 사용자의 위치 정보(예를 들어, 현재 셀, 현재 VLR) 및 사용자 프로파일(예를 들어, IMSI, 패킷 데이터 네트워크에서 이용되는 주소(들))을 저장한다.

M2M/MTC 통신은 인간 상호작용을 수반하는 종래의 데이터 통신과 상이하다. 예를 들어, 데이터 통신을 요구하는 M2M/MTC 애플리케이션들이 모두 동일한 특성을 갖는 것은 아니다. 각각의 타입의 M2M/MTC 애플리케이션은 상이한 타입들의 통신 서비스를 요구할 수 있다. 3GPP TS 22.368은 이들 상이한 서비스 요구조건들을 식별하고 이러한 서비스들을 제공하기 위한 상이한 MTC 피쳐들을 열거한다. 예를 들어, MTC 피쳐 '낮은 이동성'은, 이동하지 않거나, 빈번하지 않게 이동하거나, 소정 지역 내에서만 이동하는 MTC 디바이스와 함께 이용하기 위한 것이다. MTC 피쳐 '시간 제어형'은 정의된 시구간 동안만 데이터를 전송 또는 수신하고 이러한 정의된 시구간 외에서는 불필요한 신호를 피하도록 용인될 수 있는 MTC 애플리케이션과 함께 이용하기 위한 것이다. MTC 피쳐 '소량 데이터 전송'은 소량의 데이터를 전송하거나 수신하는 MTC 디바이스와 함께 이용하기 위한 것이다. MTC 피쳐 '덜 빈번한 모바일 종료형'은 주로 모바일 발신 통신을 이용하는 MTC 디바이스와 함께 이용하기 위한 것이다. MTC 피쳐 'MTC 모니터링'은 MTC 디바이스-관련 이벤트를 모니터링하기 위한 것이다. MTC 피쳐인 '보안 접속'은 MTC 디바이스와 MTC 서버/MTC 애플리케이션 서버 사이에서 보안 접속을 요구하는 MTC 디바이스와 함께 이용하기 위한 것이다. 마지막으로, MTC 피쳐 '그룹 기반'은 MTC 디바이스들의 그룹에 적용되며, 그룹 기반 정책, 그룹 기반 주소지정 등을 포함한다.

기존의 3GPP 네트워크에서, 애플리케이션 계층 데이터 통신은 주로 패킷 영역을 통해 및 SMS를 통해 지원된다. (i) 패킷 영역(SGi 및 Gi 기준점, (ii) SMS(Short Message Service), (iii) 멀티미디어 메시징 서비스(MMS), 및 (iv) 비-액세스 스트라텀(NAS)을 포함한, 수 개의 상이한 트랜스포트 메커니즘이 이용가능하다.

패킷 영역 메시징과 관련하여, PGW 및 GGSN은 데이터 통신을 위한 앵커 지점(anchor point)으로서 동작하고 코어 네트워크 내의 GTP-U 터널(PMIP도 역시 S5/S8 인터페이스에서 이용될 수 있음)을 통해 사용자 평면 데이터를 라우팅한다. 3GPP TS 23.401은 이 EPC 아키텍쳐를 정의한다. GTP-U 터널은 이들을 통해 트랜스포트되는 IP 흐름에 공통 QoS 처리를 제공한다. 패킷 필터는 지정된 GTP-U 터널을 통해 트랜스포트될 흐름을 결정한다.

SMS의 목적은, 3GPP TS 23.040에 기술된 바와 같이, SC(서비스 센터)를 통해 MS/UE와 SME(단문 엔티티) 사이에서 단문 메시지를 전송하는 수단을 제공하는 것이다. SMS는 주로 사용자들 사이에서 단문 메시지를 교환하는 데 이용된다. 그러나 SMS는 짧은 데이터 통신을 위해 일부 상위층 애플리케이션에서 이용될 수도 있다. SMS는 또한, 저장 및 포워딩 메커니즘을 제공할 수 있다. SMS는 보통의 사용자 평면 데이터와는 상이하게 라우팅되며 일반적으로 SGi/Gi 인터페이스 경로를 이용하지 않는다.

MMS는 멀티미디어 메시징 컨텍스트(multimedia messaging context)에서 가입자에게 풍부한 콘텐츠 세트를 제공하기 위해 이용되는 서비스이다. 이것은 SMS와 유사한 저장-및-포워딩 이용 패러다임을 제공한다. 그러나, MMS는 패킷 영역 사용자 평면(SGi/Gi)을 이용하여 멀티미디어 메시지를 트랜스포트한다. MMS는 사용자 평면에 걸쳐 실행되는 애플리케이션 레벨 서비스로 간주될 수 있다. 3GPP TS 23.140은 MMS 아키텍쳐를 기술한다. MMS는 멀티미디어 메시지의 수신자를 어드레싱하기 위해 전자메일 주소(RFC 2822) 또는 MSISDN(E.164) 또는 양쪽 모두의 이용을 지원한다. MMS는 멀티미디어 메시지의 수신자를 어드레싱하기 위해 서비스 제공자 고유 주소의 이용을 지원할 수도 있다.

NAS에 관해서는, 3GPP SA2 내에서, MTC-IWF가 T5 인터페이스를 이용하여 SGSN/MME에 소량의 데이터 메시지를 전송한 다음 NAS 또는 RRC 메시지를 이용하여 UE에 데이터를 전송하는 것을 허용하는 것에 관한 논의가 있었다. 이 피쳐는 아직 3GPP에 의해 지원되지 않지만, 향후 일부 이러한 서비스가 지원될 것으로 예상된다.

3GPP 네트워크에서의 데이터 전송을 위한 또 다른 기존의 메커니즘은 디바이스 트리거링(device triggering)이라고 부른다. 디바이스 트리거링은, SCS가 3GPP 네트워크를 통해 UE에게 정보를 전송하여 SCS와의 통신 개시를 포함하는 애플리케이션 특유의 동작을 수행하도록 UE를 트리거하는 수단이다. 3GPP TS 23.682는 3GPP 네트워크에 의해 지원되는 디바이스 트리거 메커니즘을 정의한다. 디바이스 트리거링은, UE에 대한 IP 주소가 이용가능하지 않거나 SCS/AS에 의해 도달될 수 없는 경우에 요구된다.

디바이스 트리거링이 필요한지를 결정하기 위하여, SCS/AS는 디바이스의 IP 주소의 유효성을 추적해야 할 것이다. 디바이스가 너무 오랫동안 유휴 상태인 경우 네트워크/PDN이 M2M 디바이스에 할당된 IP 주소를 다른 UE에 재할당할 수 있다. 일부 경우, SCS/AS는 SCS/AS에게 알려진 디바이스의 IP 주소를 이용하여 초기 통신을 시도할 수 있으며, 통신이 실패한 후(아마도 ICMP 메시지에 기초하여) 그 IP 주소가 유효하지 않다는 것을 검출할 수 있다. 이것은 M2M 디바이스와의 통신 확립에 대해 시간 소모적일 수 있다. 또한, 기존의 디바이스 트리거 접근법은, 애플리케이션 데이터를 교환하기 이전에 디바이스 트리거링이 필요한지를 SCS/AS가 결정할 것을 요구하며, SCS/AS는 디바이스 트리거링 메시지를 작성하고 디바이스 트리거링 절차를 시작해야 할 것이다.

본 출원은, 제한없이, 3GPP MTC 아키텍쳐 등의, M2M 또는 MTC 통신 네트워크 내의 애플리케이션들 사이의 애플리케이션 데이터 전송을 위한 새로운 방법 및 시스템을 개시한다.

전술된 바와 같이, M2M/MTC 통신은 인간을 수반하는 종래의 통신과는 상이한 특성을 갖는다. 일부 M2M/MTC 애플리케이션은 즉각적인(낮은 레이턴시) 데이터 전송을 요구할 수 있는 반면 다른 M2M 통신은 몇 일 정도의 지연을 용인할 수 있다. 3GPP는 데이터를 전송하는 데 이용할 수 있는 수 개의 방법을 가지고 있으며 제어 평면을 통해 소량의 사용자 데이터 패킷을 전송하기 위한 방법을 개발하고 있지만, 이러한 기존 방법들은 데이터를 전송하는 애플리케이션의 기본적인 기저 통신 요건을 고려하지 않는다. 애플리케이션 데이터를 전송하는 코어 네트워크 노드 또는 애플리케이션 서버(즉, SCS)는 어떤 데이터 트랜스포트 방법이 선택되는지에 영향을 미치지 못한다. 애플리케이션 인식 기능을 EPC 내에 도입함으로써, EPC는, 단지 QoS 및 IP 흐름 제어보다도 더욱 효율적인 트랜스포트 서비스 뿐만 아니라 더욱 애플리케이션-인식형의 서비스를 애플리케이션들에게 제공할 수 있다.

애플리케이션 인식은 또한 트리거링을 더욱 효율적으로 할 수 있다. 3GPP 네트워크에서의 기존의 디바이스 트리거링 메커니즘은, 트리거가 SCS에 의해 시작될 것을 요구한다. SCS는 UE의 상태를 결정하고 트리거가 필요한지를 결정할 것으로 예상된다. 마찬가지로, SCS는 소량의 데이터 전송을 이용하려고 할 때를 코어 네트워크에 표시해야 한다. SCS는 최적의 데이터 전달 방법을 알 것으로 예상된다. 그러나 이러한 결정들은 SCS의 지원을 통해 코어 네트워크에 의해 더욱 지능적으로 또는 효율적으로 이루어 질 수 있다.

3GPP 네트워크에서의 복수의 상이한 데이터 트랜스포트 메커니즘의 존재도 역시 M2M/MTC 애플리케이션 개발을 더욱 어렵게 한다. 개발자가 상이한 시나리오들에서 상이한 트랜스포트 메커니즘을 활용하려는 경우, 애플리케이션 개발자는 이들 상이한 메커니즘들 각각에 대해 코딩해야 하며 주어진 상황에서 적절한 메커니즘을 선택하는 데 필요한 코드도 역시 제공해야 한다.

기존 기술들에서의 이러한 결점을 해결하기 위해, 본 출원은, 디바이스 영역(예를 들어, M2M/MTC 디바이스들 및 게이트웨이들)에 존재할 수 있는 애플리케이션들과 네트워크 영역(예를 들어, AS 또는 SCS)에 존재하는 애플리케이션들 사이의 애플리케이션 데이터 전송을 용이하게 하는, 여기서는 애플리케이션 데이터 전달 서비스(ADDS)라고도 하는, 새로운 서비스를 개시한다. 또한, ADDS와 3GPP 코어 네트워크 노드 사이에서 새로운 데이터 전달 서비스를 제공하는 새로운 인터페이스(즉, 기준점)가 개시된다.

한 실시예에서, 애플리케이션들 각각에는, ADDS 서비스에 대한 애플리케이션을 식별하는 고유한 ADDS 서비스 특유의 식별자가 할당된다. 이 식별자는 다양한 3GPP 계층 식별자들에 관한 추상화를 제공하고 ADDS 서비스 및 애플리케이션들을 호스팅하는 엔드 노드들이 ADDS 특유의 기능을 원활하게 제공하는 것을 돕는다. 이 애플리케이션 식별자에 의해, 애플리케이션은, IP 주소, FQDN, 외부 ID, MSISDN 등과 같은 다른 트랜스포트 계층-특유의 ID를 알아야 할 필요가 없다.

한 실시예에서, ADDS는, NAS, SMS, USSD, 및 사용자 평면 등의 기존의 3GPP 트랜스포트 메커니즘을 활용하고, 애플리케이션 데이터 특성, 애플리케이션/엔드 노드 특성 및 가용성, 가입 정보, 네트워크의 정책, (정체, 노드 가용성 등의) 네트워크 상태 등의 기준에 기초하여 애플리케이션 데이터를 전달하기 위한 트랜스포트 메커니즘을 선택하도록 구성된다.

ADDS에 의해 제공되는 다른 피쳐들로서는, 애플리케이션 이동성(네트워크에 액세스하는 모드가 변경되더라도 애플리케이션이 ADDS 서비스 이벤트를 계속 이용하는 능력), 저장 및 포워드 기능 및 이후에 명백해질 기타의 것들이 포함된다.

본 요약은, 이하의 상세한 설명에서 더 설명되는 선발된 개념들을 간략화된 형태로 소개하기 위해 제공되는 것이다. 본 요약은, 청구 대상의 핵심 피쳐나 본질적 피쳐들을 식별하기 위함도 아니고, 청구 대상의 범위를 제한하기 위해 이용되는 것도 아니다. 또한, 청구 대상은 본 개시의 임의의 부분에서 언급된 임의의 또는 모든 단점을 해결하는 한도로 제한되지 않는다.

전체를 통해 유사한 번호들은 유사한 요소들을 가리키는 첨부된 도면들과 연계하여, 예를 통해 주어지는 이하의 상세한 설명으로부터 더 상세한 이해를 얻을 수 있다. 도면에서:
도 1은 3GPP 코어 네트워크 아키텍쳐의 기본 아키텍쳐 도면이다.
도 2는 3GPP 머신 타입 통신(MTC) 아키텍쳐의 블록도이다.
도 3은, 본 발명의 한 실시예에 따른, ADD 클라이언트 및 ADDS 엔티티를 포함하는 새로운 애플리케이션 데이터 전달 서비스(ADDS)의 아키텍쳐의 고수준 개요를 나타내는 블록도이다.
도 4a는 ADDS 엔티티가 코어 네트워크 내의 별개의 논리적 노드로서 구현되는 ADDS의 한 실시예를 나타내는 블록도이다.
도 4b는 ADDS 엔티티가 3GPP MTC-IWF와 함께 배치된 실시예를 나타낸다.
도 4c는 ADDS 엔티티가 3GPP PGW의 일부로서 통합된 실시예를 나타낸다.
도 4d는 ADDS 엔티티가 서비스 영역의 일부이고 3GPP 네트워크 오퍼레이터에 대한 외부 엔티티일 수 있는 또 다른 실시예를 나타낸다.
도 4e는 ADDS 엔티티가 3GPP IP 멀티미디어 서브시스템(IMS) 애플리케이션 서버(AS)로서 구현되는 역시 또 다른 실시예를 나타낸다.
도 5는 ADDS 클라이언트 및 ADDS 클라이언트를 이용하는 애플리케이션들이 동일한 엔드 노드에 존재할 때, ADDS 클라이언트의 아키텍쳐의 한 실시예를 나타낸다.
도 6은, ADDS 클라이언트가, ADDS 클라이언트를 호스팅하는 엔드 노드와는 상이한 물리적 디바이스에서 실행되는 애플리케이션들과 인터페이스하는, ADDS 클라이언트의 아키텍쳐의 또 다른 실시예를 나타낸다.
도 7은 UE로의 ADDS 광고를 위한 방법의 한 실시예를 나타낸다.
도 8은 UE로의 ADDS 광고를 위한 방법의 또 다른 실시예를 나타낸다.
도 9는 UE로의 ADDS 광고를 위한 방법의 역시 또 다른 실시예를 나타낸다.
도 10은 SCS로의 ADDS 광고를 위한 방법의 한 실시예를 나타낸다.
도 11a는 NAS를 통한 ADDS 메시지 전송을 위한 프로토콜 스택을 도시한다.
도 11b는 사용자 평면을 통한 ADDS 메시지 전송을 위한 프로토콜 스택을 도시한다.
도 11c는 SMS를 이용한 ADDS 메시지 전송을 위한 프로토콜 스택을 도시한다.
도 11d는 USSD를 이용한 ADDS 메시지 전송을 위한 프로토콜 스택을 도시한다.
도 12는 본 발명의 한 실시예에 따른 ADDS 메시지의 포멧을 나타낸다.
도 13은 본 발명의 실시예에 따른 애플리케이션 등록 방법에 대한 예시적 콜 흐름을 도시한다.
도 14는 엔드 노드 또는 네트워크가 ADDS 업데이트 절차를 개시하고 수행하는 프로세스의 실시예를 나타낸다.
도 15는 한 실시예에 따른 ADDS 데이터 전송 프로세스를 나타내는 흐름도이다.
도 16은 본 발명의 한 실시예에 따른 ADDS 이벤트 가입을 위한 방법을 나타낸다.
도 17은 엔드 노드에 의해 또는 네트워크에 의해 개시되는 애플리케이션 등록 취소를 위한 방법의 실시예를 나타낸다.
도 18은 ADDS 클라이언트가 존재할 수 있는 예시적 엔드 노드의 도면이다.
도 19는, ADDS 엔티티 또는 ADDS 클라이언트가 구현될 수 있는 임의의 노드를 포함한, 도 1 내지 도 17에 나타낸 코어 네트워크 노드들 또는 엔드 포인트들 중 임의의 것을 구현하는 데 이용될 수 있는 컴퓨터 시스템 또는 서버의 블록도이다.

ADDS 아키텍쳐

도 3은, 본 발명의 한 실시예에 따른, 새로운 애플리케이션 데이터 전달 서비스(ADDS)의 아키텍쳐의 고수준 개요를 나타내는 블록도이다. 이 실시예에서, ADDS는, 3GPP 코어 네트워크(즉, EPC)(102)에 배치된 ADDS 엔티티(322) 및 시스템(300)에서 데이터 전송을 위해 ADDS를 이용할 수 있는 다양한 엔드 노드들에서 호스팅되는 복수의 ADDS 클라이언트(324)에 의해 구현된다. ADDS를 이용할 수 있는 엔드 노드로서는, SCS(Service Capability Server)(306) 또는 AS(Application Server)(308 또는 310) 등의 네트워크 엔티티뿐만 아니라 UE(312 및 318) 등의 사용자 장비(UE)가 포함된다.

UE는, 예를 들어, 머신, 센서, 가전 제품 등을 포함하는 M2M 또는 MTC 디바이스 또는 게이트웨이 등의 3GPP 또는 기타의 무선 네트워크에서 통신할 수 있는 임의의 무선 디바이스, 이동국, 고정된 또는 모바일 가입자 유닛, 페이저, 개인 디지털 보조도구(PDA), 컴퓨터, 모바일 전화 또는 스마트폰, 또는 유선 또는 무선 환경에서 동작할 수 있는 기타 임의 타입의 디바이스를 포함할 수 있다. UE의 예시적 아키텍쳐는 도 18과 관련하여 이하에서 설명된다. SCS 또는 AS(예를 들어, AS(308, 310)의 SCS(306))는, 도 19와 관련하여 이하에서 설명되는 예시적 컴퓨팅 시스템 또는 서버 등의 컴퓨팅 시스템 또는 서버 상에 구현될 수 있다.

한 실시예에서, ADDS 클라이언트(324)는, UE, SCS 또는 AS의 메모리에 저장될 수 있고 그 디바이스의 프로세서 상에서 실행될 수 있는 논리적 엔티티(예를 들어, 소프트웨어)이다. 그러나, 다른 실시예들에서, ADDS 클라이언트는 완전히 하드웨어로 또는 하드웨어와 소프트웨어의 임의의 조합으로 구현될 수도 있다. UE 상의 ADDS 클라이언트(324)는, 네트워크에서 데이터 전송을 위해 ADDS를 이용하고자, UE 상에서 실행 중인 애플리케이션(예를 들어, UE(312)에서 실행 중인 App3 및 App4 또는 UE(318)에서 실행 중인 App5 및 App6) 또는 다른 디바이스 상에서 실행 중인 애플리케이션(예를 들어, 디바이스(314)에서 실행 중인 App1 및 App2)과 인터페이스한다. 마찬가지로, SCS(예를 들어, SCS(306))에서 호스팅되는 ADDS 클라이언트(324)는, SCS에서 실행중인 애플리케이션(예를 들어, SCS App) 또는 SCS와 통신하는 AS 상에서 실행 중인 애플리케이션(예를 들어, AS(308) 상에서 실행 중인 App1 및 App2)과 인터페이스할 수 있다. 역시 도시된 바와 같이, ADDS 클라이언트(324)는 AS 상에 호스트될 수 있고, 그 AS상에서 실행 중인 애플리케이션들(예를 들어, AS(310) 상에서 실행 중인 App3 및 App4)과 직접 인터페이스할 수 있다. 역시 도시된 바와 같이, UE 상에서 실행 중인 ADDS 클라이언트(324)는 3GPP 액세스 네트워크(316) 또는 비-3GPP 액세스 네트워크(320) 중 어느 하나를 이용하여 EPC(102) 내의 ADDS 엔티티(322)와 통신할 수 있다.

ADDS 엔티티(322)는 또한, EPC(102) 내의 독립형 노드 또는 서버 상에서 또는 기존 노드나 서버의 일부로서 실행되는 논리적 엔티티(예를 들어, 소프트웨어)로서 구현될 수 있다. 이와 관련하여 다양한 실시예가 이하에서 더 충분히 논의된다. SCS, AS, 또는 EPC(102) 내의 임의의 노드 또는 엔티티와 같이, ADDS 엔티티(322)는 또한, 도 19와 관련하여 이하에서 설명되는 것과 같은 컴퓨터 시스템 또는 서버 상에 구현될 수도 있다.

일반적으로, ADDS는 애플리케이션 메시지 교환을 위한 게이트웨이로서 동작하고, 네트워크를 통한 데이터의 최적화된 전송을 가능하게 한다. ADDS는 애플리케이션 계층이 애플리케이션의 특성 및 전송되는 데이터의 특성을 제공하는 것을 허용하며, 이 특성은, 데이터를 전달하기 위한 최적의 트랜스포트 메커니즘(예를 들어, SMS, NAS, USSD, 사용자 평면 등)을 선택하는 데 있어서 ADDS 엔티티에 의해 이용될 수 있다. 엔드 노드에 존재하는 ADDS 클라이언트(324)는 자신이 서비스하고 있는 애플리케이션을 네트워크의 ADDS 엔티티(322)에 등록하고, 이들 애플리케이션 및 엔드 노드 디바이스의 특성을 ADDS 엔티티(322)에 전달한다. ADDS 클라이언트(324)는, 애플리케이션들, 그들의 상태 및 특성을 추적한다. 도 3에 나타낸 바와 같이, 애플리케이션들 및 ADDS 클라이언트(324)는 동일한 물리적 디바이스 상에 공존할 필요가 없다. 예를 들어, M2M 네트워크에서, 애플리케이션은, M2M 디바이스(예를 들어, 도 3의 디바이스(314)) 상에서 실행 중인 디바이스 애플리케이션(DA)일 수 있고, ADDS 클라이언트(324)는 M2M 디바이스를 서비스하는 M2M 게이트웨이(예를 들어, 도 3의 UE(312)) 상에 존재할 수 있다. 다운링크 방향에서, ADDS 클라이언트(324)는 수신된 메시지를 올바른 애플리케이션에 전송하는 것을 담당한다. 업링크 방향에서, ADDS 클라이언트(324)는 네트워크 ADDS 엔티티(322)에 의해 제공된 정책들/명령들에 기초하여 메시지를 전송하기 위해 적절한 트랜스포트 메커니즘(SMS, NAS, 이용 평면 등)을 선택할 것이다.

ADDS 엔티티(322)는 주어진 ADDS 클라이언트(324)와의 애플리케이션의 연관을 추적 및 유지하고 애플리케이션을 위해 메시지를 적절한 ADDS 클라이언트(324)에 라우팅한다. 언급된 바와 같이, ADDS 클라이언트(324)는 메시지를 적절한 애플리케이션에 라우팅한다. 한 실시예에서, ADDS는, ADDS 내의 그 애플리케이션을 고유하게 식별하기 위해, 여기서는 애플리케이션 ID라고 지칭되는, 고유 식별자를 각각의 애플리케이션에 할당한다.

따라서, ADDS는 데이터 통신 수단이며, 그 통신 필요성을 위해 (M2M 네트워크에서 SCS와 같은) 서비스 계층 또는 (M2M 네트워크 또는 AS 내의 NA와 같은) 애플리케이션 계층 내의 임의의 애플리케이션/엔티티에 의해 이용될 수 있다. 애플리케이션 ID가 알려져 있는 한, 어떠한 엔티티도, 전송 애플리케이션/엔드 노드가 인가되고 ADDS 클라이언트(324)에 인터페이스되는 한, 그 애플리케이션에 메시지를 전송할 수 있다. ADDS는 주로 M2M/MTC 통신의 맥락에서 설명될 수 있지만, ADDS는 그러한 통신으로 제한되지 않고 비-M2M 애플리케이션 및 노드에 의해 이용될 수도 있다는 것을 이해해야 한다. 예를 들어, ADDS는, UE 상에서 실행 중인 애플리케이션과 네트워크 측의 외부 애플리케이션 서버 상의 애플리케이션 사이의, 한 UE 상에서 실행 중인 애플리케이션으로부터 다른 UE 상에서 실행 중인 애플리케이션으로의, 네트워크 측의 서버/노드 상의 애플리케이션으로부터 다른 서버/노드 상의 다른 애플리케이션으로의 통신에 이용될 수 있다.

전술된 바와 같이, ADDS 엔티티는 논리적이며 별개의 엔티티로서 구현되거나, 3GPP MTC 아키텍쳐의 PGW 또는 MTC-IWF 등의, 다른 네트워크 노드의 기능적 부분으로서 병합될 수 있다. 다양한 대안들 이하에서 설명된다. ADDS는 3GPP 제어 평면 또는 사용자 평면 경로를 통해 메시지를 전송할 수 있기 때문에, 제어 평면 노드(MME, HSS 등) 및 사용자 평면 노드(PGW 등) 양쪽 모두와 통신할 수 있고, 그에 따라 이하에서 설명되는 다양한 대안들은 ADDS 엔티티(322)가 어떻게 사용자 평면 및 제어 평면 양쪽 모두에서 상이한 방식으로 통합될 수 있는지를 나타낸다.

도 4a는 ADDS 엔티티(322)가 코어 네트워크 내의 별개의 논리적 노드로서 구현되는 ADDS의 한 실시예를 나타내는 블록도이다. eNodeB(106), SGW(110), PGW(112), MME(114), HSS(116), SMS-SC(204), MTC-IWF(210) 및 MSC(238)를 포함하는, 도 4a에 나타낸 코어 네트워크 노드들의 대부분은 전술되었고 또한 도 1 및/또는 도 2에서 예시되었다. 도 4a는 3개의 추가적인 코어 네트워크 노드, 즉, 온라인 과금 시스템(OCS)(330), 오프라인 과금 시스템(OFCS)(332), 정책 및 과금 규칙 기능(PCRF)(334)을 소개하고 있다.

OCS(330), OFCS(332), 및 PCRF(334)는 네트워크에서 과금 및 청구를 담당하는 코어 네트워크 내의 논리적 엔티티/기능이다. 이들은 과금 정보의 생성 및 수집을 처리한 다음, 적절한 과금 및 청구 시스템에 포워딩한다. 온라인 과금이란, 과금 정보가, 렌더링되는 서비스에 실시간으로 영향을 미칠 수 있는 메커니즘을 말한다. 오프라인 과금이란, 과금 정보가, 렌더링되는 서비스에 실시간으로 영향을 미치지 않는 메커니즘을 말한다. OCS(330)는 온라인 과금에 대한 실시간 신용 제어를 수행하는 엔티티이다. 그 기능으로는, 트랜잭션 처리, 평가, 온라인 상관 및 가입자 계정/잔고의 관리가 포함된다. OFCS(332)는 온라인 과금 기능을 처리하는 반면, OFCS(332)는 오프라인 과금 정보를 과금 시스템에 전달하기 이전에 수집하고 처리하는 엔티티다. PCRF(334)는 PGW(112)와 인터페이스하여 이를 위해 과금 집행 결정을 한다. 이것은 네트워크 오퍼레이터를 위한 정책 결정 지점으로서 역할할 수 있다. 예를 들어, 서비스 제공자는 PCRF(334)를 이용하여 고-대역폭 애플리케이션 이용량에 기초해 가입자에게 과금하고, QoS 보장에 대한 추가 요금을 부과하며, 사용자가 로밍하는 동안 애플리케이션 이용을 제한하거나, 피크 이용 시간 동안에 과중한-대역폭의 애플리케이션을 이용하여 무선 가입자의 대역폭을 낮출 수 있다.

ADDS 엔티티(322)가 코어 네트워크 내의 독립형 엔티티인 도 4a에 나타낸 실시예에서, ADDS 엔티티(322)는, 새로이 정의된 기준점들 ― AD1, AD2, AD3, AD4, AD5, AD6, AD7, AD8, AD9, AD10 및 AD11을 통해, SCS 또는 AS(340) 등의 외부 엔티티 뿐만 아니라 다른 코어 네트워크 엔티티와 인터페이스한다. 본 실시예에서, 이러한 기준점들은 네트워크에서 ADDS 기능을 가능하게하기 위한 전용 인터페이스이다. 각각의 기준점은 이하에서 더 상세히 설명된다.

도 4a에 나타낸 실시예에서, SCS 또는 AS(340) 등의 임의의 외부 노드는 ADDS 서비스를 이용하기 위하여 ADDS 엔티티(322)에 접속할 것이다. ADDS 엔티티(322)는 UE들(예를 들어, UE(338))에게 메시지를 전송하고 수신할 것이다. ADDS 엔티티(322)와 PGW(112) 사이의 통신을 위해 모바일 네트워크 오퍼레이터(MNO)에 의해 별도의 사설 패킷 데이터 네트워크(PDN)(342)가 이용될 수 있다.

단일의 ADDS 엔티티(322)가 도 4a에 도시되어 있지만, 다른 실시예에서는, 복수의 별개로 어드레싱가능한 ADDS 엔티티들(미도시)이 있을 수 있다. 이것은 오퍼레이터가 패킷 데이터 네트워크 기반의 또는 가입자들의 서브셋에 대한 ADDS 기능을 가능하게 하는 것을 허용할 수 있다.

도 4b 내지 도 4e는, ADDS 엔티티(322)가 다른 코어 네트워크 노드들과 통합되거나 EPC에 대한 외부 엔티티로서 서비스 영역의 일부로서 배치되는 다른 실시예들을 나타낸다. 이들 다른 대안적인 실시예에서, 여기서 정의된 새로운 기준점들(AD1 내지 AD11)은 기존의 기준점들에 병합되거나 맵핑될 수 있다. 도 4b 내지 도 4e의 각각의 도면은 ADDS 서비스에 대해 여기서 정의된 새로운 기준점들에 병합되거나 맵핑될 수 있는 기존의 기준점들을 도시한다.

도 4b는 ADDS 엔티티(322)가 MTC-IWF(110)와 함께 배치되는 실시예를 나타낸다. 즉, ADDS 엔티티(322)의 논리적 기능은 MTC-IWF(110)의 논리적 기능을 구현하는 동일한 컴퓨터 시스템 또는 서버 상에 구현된다. ADDS 엔티티(322)가 SCS 또는 AS(340)의 ADDS 클라이언트(324)와 인터페이스하기 위해 이용하는 AD1 기준점(프로토콜 및 절차)은 3GPP Tsp 인터페이스에 통합되거나 이에 맵핑될 수 있고, AD1 기준점의 정보 요소(IE)들은 그 실시예에서 다이어미터(Diameter) 프로토콜 ―Tsp 및 기타의 기존의 3GPP 기준점을 통해 메시지를 전송하는 데 이용되는 프로토콜―을 이용하여 AVP(Attribute-Value Pairs)로서 전송될 수 있다. 이 실시예는, MTC-IWF(210)가 이미 HSS(116), SCS 또는 AS(340)와 같은 다른 노드들과 함께 갖는 인터페이스들이 ADDS 기능을 지원하도록 강화될 수 있기 때문에 유익할 수 있다. 예를 들어, AD6 인터페이스는 3GPP S6m 인터페이스에 맵핑될 수 있고, AD5 인터페이스는 3GPP T5 인터페이스에 맵핑될 수 있으며, AD4 인터페이스는 3GPP T4 인터페이스에 맵핑될 수 있다.

도 4c는 ADDS 엔티티(322)가 PGW(112)의 일부로서 통합되는 실시예를 나타낸다. 이 실시예는, 네트워크 오퍼레이터가 특정 PDN 상의 AS/SCS 및 그 특정 PDN에 접속하는 UE들만이 ADDS 서비스를 이용하도록 허용하는 PDN 기반의 ADDS 기능을 가능하게 하기를 원하는 경우에 유익할 수 있다. 예를 들어, 도시된 바와 같이, 네트워크 오퍼레이터는 ADDS 엔티티(322)의 하나의 인스턴스가 외부 PDN(346a)을 서비스하는 PGW(112a)와 통신하도록 허용할 수 있고, 오퍼레이터는 ADDS 엔티티(322)의 제2 인스턴스가 외부 PDN(346b)을 서비스하는 PGW(112b)와 통신하는 것을 허용할 수 있다. 외부 네트워크(346a) 상의 SCS/AS(340a)만이 PGW(112a) 상의 ADDS 엔티티에 의해 제공되는 ADDS 서비스를 이용할 수 있다. 유사하게, SCS/AS(340b)만이 PGW(112b) 상의 ADDS 엔티티에 의해 제공되는 ADDS 서비스를 이용할 수 있다.

도 4c에서, HSS(116)는 가입 프로파일 저장소(SPR) 또는 사용자 데이터 저장소(UDR)일 수 있는 논리적 엔티티(352)로 대체된다는 점에도 역시 유의한다. SPR(352)은 PCRF(334)에 의한 가입-기반 정책 및 베어러 레벨 과금 규칙에 필요한 모든 가입자/가입 관련 정보를 포함하는 3GPP 논리적 엔티티이다. UDR은 3GPP 아키텍쳐에서 최근에 도입된 새로운 개념이다. 오늘날, 가입자 데이터는 수 개의 상이한 엔티티들에 존재할 수 있다. HSS는 가입자 데이터가 저장되는 가장 잘 알려진 엔티티들 중 하나이지만, 가입자 데이터는 SPR 및 UDR 등의 장소에 저장될 수도 있다. UDR의 배경 개념은 모든 가입자 정보가 한 장소(UDR)에 저장된다는 것이다. UDR은 가입자 데이터에 액세스하는 데 이용할 수 있는 단일 인터페이스(Ud)를 제공한다. 이 실시예에서, PCRF(334)(Gx), 가입 프로파일 저장소(SPR)(352)(Sp) 및 UDR(Ud)를 갖는 PGW의 기존 인터페이스는 ADDS 기능을 제공하도록 강화될 수 있다. OFCS(332) 및 OCS(330)가 있는 PGW의 기존 인터페이스들도 역시 ADDS를 지원하도록 강화될 수 있다. 또한, 이 실시예에서, 별도의 사설 PDN이 필요하지 않을 수도 있다.

도 4d는 ADDS 엔티티(322)가 서비스 영역의 일부이고 3GPP 네트워크 오퍼레이터에 대한 외부 엔티티인 또 다른 실시예를 나타낸다. 도 4d에서, ADDS 엔티티(322)는 서비스 영역 내의 별개의 엔티티이지만, SCS의 일부로서 구현될 수도 있다. 이 실시예에서 ADDS 엔티티(322)는 기존의 3GPP Tsp, Mh, Mo, Mf, Rx 및 SGi/Gi 인터페이스를 이용하여 코어 네트워크와 상호작용할 수 있다. Mh 및 Tsp 인터페이스는, 디바이스 구성, 모니터링 및 보고, 가입 정보 수신, 디바이스 트리거링 등(AD4와 유사)에 이용될 수 있다. Rx 인터페이스는 정책 정보를 제공하고 수신하는 데 이용될 수 있다(AD3과 유사).

도 4e는 ADDS 엔티티가 3GPP IP 멀티미디어 서브시스템(IMS) 애플리케이션 서버(AS)로서 구현되는 역시 또 다른 실시예를 나타낸다. 이 실시예에서, S-CSCF(354), HSS(116), OFCS(332), OCS(330) 및 PCRF(334)로의 AS(322)의 접속은, 각각, AD11, AD6, AD9, AD8 및 AD3 기준점들을 배치하는 데 이용될 수 있다. S-CSCF(서빙 콜 세션 제어 기능)는 시그널링 평면의 중앙 노드로서 역할하는 3GPP IMS 네트워크 아키텍쳐의 논리적 엔티티이다. 이것은 SIP(Session Initiation Protocol) 서버이지만, 세션 제어도 수행한다. 이것은 다이어미터(Diameter) 프로토콜의 Cx 및 Dx 인터페이스를 이용해 HSS에 인터페이스하여 사용자 프로파일을 다운로드하고 사용자-대-S-CSCF 연관을 업로드한다. 모든 필요한 가입자 프로파일 정보는 HSS로부터 로드된다.

도 4e의 실시예에서, UE(214)와 IMS AS(322') 사이의 HTTP 기반 Ut 기준점은 IMS AS(322') 내의 ADDS 엔티티의 AD1 기준점에 대한 데이터 평면 통신을 운반하는 데 이용될 수 있다. ISC/AD11 기준점은, SIP 메시징을 통해 ADDS 클라이언트(324)에 메시지를 전송하기 위해 IMS AS(322')에 의해 이용될 수 있다.

ADDS 기준점들

도 3 및 도 4a 내지 도 4e에 나타낸 바와 같이, ADDS 서비스는 새로운 기준점들(즉, 인터페이스들) AD1 내지 AD11의 정의를 포함한다. 기준점 및 인터페이스라는 용어는 여기서는 동의어로 사용된다. 각각의 기준점/인터페이스가 이하에서 상세히 설명된다.

AD1 - AD1 기준점은 엔드 노드상의 ADDS 클라이언트(324)와 EPC 내의 ADDS 엔티티(322) 사이에 존재한다. ADDS 제어 및 데이터 메시지는 이 기준점을 통해 전송된다. 이 기준점 상의 ADDS 메시지는 3GPP 네트워크 제어 평면 또는 사용자 평면을 통해 트랜스포트될 수 있다. 이 기준점은 특히: (1) 애플리케이션을 ADDS 엔티티에 등록/등록 취소하고; (2) 애플리케이션 페이로드를 전송하며; (3) 애플리케이션 관련 이벤트에 가입하고; (4) 엔드 노드 능력, 상태 정보, 스케쥴 및 통신 요건을 업데이트하는 데 이용될 수 있다.

AD2 - AD2 기준점은 엔드 노드 상의 애플리케이션들과 그 엔드 노드 상의 ADDS 클라이언트(324) 사이에 존재한다. 이 인터페이스는 애플리케이션이 ADDS 기능을 이용할 수 있게 한다. 예를 들어, 이 기준점은 애플리케이션에 의해: (1) ADDS 엔티티에 등록하고; (2) 애플리케이션 특성을 제공하며; (3) ADDS 클라이언트(324)로/로부터 애플리케이션 데이터를 전송 및 수신하기 위해 이용될 수 있다.

AD3 - AD3 기준점은 EPC 내의 ADDS 엔티티(322)와 PCRF(334) 사이에 존재한다. 이 기준점은 ADDS 엔티티(322)에 의해: (1) PCRF로부터 엔드 노드 또는 애플리케이션에 대한 정책을 요청하고; (2) 애플리케이션 및 통신 세션 특성을 PCRF에 제공하며; (3) 과금 특성과 관련된 정보를 수신하기 위해 이용될 수 있다. 한 실시예에서, ADDS 엔티티(322)가 예를 들어 도 4d의 실시예에 도시된 바와 같이 EPC의 외부에 배치된다면 AD3 인터페이스는 3GPP Rx 기준점에 기초할 수 있다. 또는, 도 4c의 실시예에 도시된 바와 같이, ADDS 엔티티(322)가 PGW(112)와 통합된다면 이것은 3GPP Gx 인터페이스에 기초할 수 있다.

AD4 - AD4 기준점은 ADDS 엔티티(322)와 3GPP SMS-SC(204) 사이에 존재한다. 이 기준점은, EPC 내의 SMS 트랜스포트 메커니즘/경로를 이용하여 UE(예를 들어, UE(214)) 상의 ADDS 클라이언트(324)와 통신하기 위해 ADDS 엔티티(322)에 의해 이용될 수 있다. 이 인터페이스의 기능은 전술된 AD1 인터페이스와 유사하지만, 구현되는 기저 트랜스포트 메커니즘은 SGi/Gi 사용자 평면 경로 대신에 SMS일 수 있다. 한 실시예에서, AD4 인터페이스는 3GPP T4 인터페이스에 기초할 수 있다.

AD5 - AD5 기준점은 ADDS 엔티티(322)와 MME(114) 사이에 존재한다. 이 기준점은 NAS 또는 RRC 트랜스포트 메커니즘을 통해 UE(214) 상의 ADDS 클라이언트(324)와 통신하기 위해 ADDS 엔티티(322)에 의해 이용될 수 있다. 이 인터페이스의 기능은 전술된 AD1 인터페이스와 유사하지만, 기저 전송 프로토콜은 SGi/Gi 사용자 평면 경로 대신에 NAS 또는 RRC 제어 평면일 것이다. 한 실시예에서, AD5 인터페이스는 T5b 인터페이스에 기초할 수 있다.

AD6 - AD6 기준점은 ADDS 엔티티(322)와 HSS(116) 사이에 존재한다. 예를 들어 도 4c의 실시예에 도시된 바와 같이, SPR 또는 UDR(352)이 코어 네트워크에서 HSS(116) 대신에 이용된다면 동일한 기준점이 역시 이용될 수 있다. 이 기준점은 ADDS 엔티티(322)에 의해: (1) 엔드 노드 및 UE의 가입 정보를 요청하고; (2) 사용자에 대한 가입 정보의 변경에 대한 통지를 수신하며; (3) 디바이스 모니터링 정보 및 디바이스 특성을 제공하고; (4) 디바이스 상태 및 능력에 대한 업데이트를 수신하며; (5) 이하에서 기술되는 ADDS 광고 절차 동안에 HSS/SPR/UDR이 이 정보를 MME에게 제공하는 것을 허용하도록 ADDS 정보 및 능력을 제공하기 위해 이용될 수 있다. 한 실시예에서, HSS(116)가 코어 네트워크에서 이용된다면, AD6은 Mh 인터페이스의 3GPP S6m에 맵핑될 수 있다. 대안으로서, UDR이 코어 네트워크에서 이용된다면, AD6 인터페이스는 3GPP Ud 인터페이스에 맵핑될 수 있고, 또는 SPR이 이용된다면 Sp 인터페이스로 맵핑될 수 있다(도 4c에 도시). 또 다른 실시예에서, ADDS 엔티티(322)는 3GPP TS 23.335에서 정의된 바와 같이 애플리케이션 프론트 엔드로서 동작할 수 있고, 상기 이용을 달성하기 위해 UDR과의 Ud 인터페이스를 갖는다.

AD7 - AD7 기준점은 ADDS 엔티티(322)와 MTC-IWF(210) 사이에 존재한다. 이 기준점은, ADDS 엔티티(322)가, 디바이스 트리거링과 같은, MTC-IWF(210)에 의해 제공되는 서비스를 이용할 수 있게 한다. 한 실시예에서, AD7 인터페이스는 3GPP Tsp 인터페이스에 기초할 수 있다.

AD8 - AD8 기준점은 ADDS 엔티티(322)와 OCS(330) 사이에 존재한다. 이 기준점은, OCS와 통신하여 ADDS 서비스에 대한 온라인 과금을 지원하기 위해 ADDS 엔티티(322)에 의해 이용될 수 있다. 한 실시예에서, AD8 인터페이스는 3GPP Ro 인터페이스에 기초할 수 있다.

AD9 - AD9 기준점은 ADDS 엔티티(322)와 OFCS(332) 사이에 존재한다. 이 기준점은, ADDS 서비스에 대한 오프라인 과금을 지원하기 위해 OFCS(332)와 통신하기 위해 ADDS 엔티티(322)에 의해 이용될 수 있다. 한 실시예에서, AD9 인터페이스는 Rf 인터페이스에 기초할 수 있다.

AD10 - AD10 기준점은 ADDS 엔티티(322)와 MSC(238) 사이에 존재한다. 이 기준점은 USSD(Unstructured Supplementary Service Data) 트랜스포트 메커니즘을 이용하여 UE(예를 들어, UE(214)) 상의 ADDS 클라이언트(322)와 통신하기 위해 ADDS 엔티티(322)에 의해 이용될 수 있다. 이 인터페이스의 기능은 전술된 AD1 인터페이스와 유사하지만, 기저 전송 프로토콜은 SGi/Gi 사용자 평면 경로 대신에 USSD일 것이다. 한 실시예에서, AD10 인터페이스는 3GPP T5c 인터페이스에 기초할 수 있다.

AD11 - AD11 기준점은 도 4e의 실시예에서 ADDS(322)와 IMS S-CSCF(354) 사이에 존재한다. 이 기준점은 SIP 메시징을 통해 UE(예를 들어, UE(214)) 상의 ADDS 클라이언트(322)와 통신하기 위해 ADDS 엔티티(322)에 의해 이용될 수 있다. 이 인터페이스의 기능은 전술된 AD1 인터페이스와 유사하다. 한 실시예에서, AD11 인터페이스는 3GPP ISC 인터페이스에 기초할 수 있다.

ADDS 기능

이 섹션은 ADDS 서비스가 애플리케이션 통신을 위해 제공하는 피쳐 및 기능을 설명한다.

애플리케이션 식별자들

ADDS 서비스의 한 실시예에서, 애플리케이션(예를 들어, 도 2의 UE(216) 상에서 실행 중인 MTC 애플리케이션(216), 또는 도 3에서 UE(312/318), 디바이스(314), SCS(306), AS(308) 또는 AS(310) 상에서 실행 중인 App1 내지 App6)은 고유한 애플리케이션 식별자(때때로 "애플리케이션 ID"라고도 함)를 할당받는다. 엔드 노드 상의 애플리케이션은, 수신 애플리케이션의 애플리케이션 식별자에 어드레싱된 ADDS 메시지를 전송함으로써 다른 애플리케이션과 통신할 수 있다.

애플리케이션 식별자는 애플리케이션을 전역적으로 고유하게 식별하는 데 이용된다. 네트워크 내의 ADDS 엔티티(322)는 애플리케이션 식별자를 할당하고, 엔드 노드에 존재하는 애플리케이션들의 목록을 유지하며, 엔드 노드 IMSI, IP 주소, MSISDN 등의, 엔드 노드의 어드레싱 정보를 갖는 엔드 노드 컨텍스트 함께 애플리케이션 식별자의 맵핑을 유지한다.

메시지가 애플리케이션 식별자에 전송될 때, ADDS 엔티티(322)는 애플리케이션이 존재하는 엔드 노드를 그것이 저장된 맵핑 테이블로부터 발견하고, 엔드 노드 IMSI, IP 주소, MSISDN 등의, 엔드 노드에 대한 어드레싱 정보를 회수한다. 엔드 노드 주소는 ADDS 메시지를 올바른 엔드 노드에 전송하는 데 이용되고, 애플리케이션 식별자는 올바른 목적지 애플리케이션에 메시지를 전달하기 위해 엔드 노드의 ADDS 클라이언트(324)에 의해 이용된다.

따라서, 애플리케이션 ID는 식별 목적에 이용되고, 엔드 노드 주소는 네트워크에서 기존의 트랜스포트 메커니즘들 중 하나를 통해 ADDS 메시지를 라우팅하기 위한 목적에 이용된다. ADDS 서비스에 의해, 애플리케이션은 자신이 통신하고자 하는 또 다른 애플리케이션이 존재하는 엔드 노드의 주소를 알 필요가 없다. 전송 애플리케이션은, 메시지를 전송/수신하고 네트워크 내의 ADDS 엔티티(322)가 엔드 노드 어드레싱 정보를 유지하도록 하기 위해 단순히 그 다른 애플리케이션의 애플리케이션 ID를 이용할 수 있다.

한 실시예에서, 애플리케이션 식별자는 이하에서 설명되는 ADDS 애플리케이션 등록 절차의 일부로서 네트워크 ADDS 엔티티(322)에 의해 할당되는 영숫자 값이다. 일부 실시예에서, 이것은 전역적으로 고유할 수 있다. 추가로, 한 실시예에서, 애플리케이션 ID의 일부는 동일한 타입이거나 소정 그룹에 속하는 애플리케이션에 대한 공통 그룹 ID가 프레픽싱될(prefixed) 수 있다. 공통 그룹 ID는, ADDS 메시지가 그룹 ID에 어드레싱될 수 있게 함으로써 그룹 통신에 이용할 수 있다. 이 실시예에서, ADDS 엔티티는, 애플리케이션 ID 내의 프레픽스로서 그룹 ID를 갖는 모든 애플리케이션들에게 메시지를 전달할 수 있다.

실시예에서, 동일한 엔드 노드 내의 동일한 애플리케이션의 상이한 인스턴스들에는 상이한 애플리케이션 식별자들이 할당될 수 있다. 추가로, 애플리케이션 식별자는 애플리케이션과 연관될 수도 있고, 애플리케이션이 해당 엔드 노드에 존재하고 있는 한, 그 애플리케이션이 현재 존재하고 있는 그 엔드 노드에 단지 일시적으로 링크될 수도 있다. 이 기능은 후술되는 애플리케이션 이동성을 지원한다.

예약된 애플리케이션 식별자들

또 다른 실시예에서, 애플리케이션 식별자들의 범위는 예약되는 것으로 간주될 수 있다. 이 실시예에서, ADDS 엔티티(322)는 이 범위 내의 애플리케이션 식별자를 할당하지 않을 수 있다. 예약된 애플리케이션 식별자는 애플리케이션을 ADDS 엔티티(322)에 등록하지 않고 애플리케이션에 의해 이용될 수 있다. 이러한 애플리케이션 식별자는 ADDS 클라이언트 내에서만 고유할 수 있고 전역적으로는 고유하지 않을 수 있다. 예약된 애플리케이션 ID 단독만으로는, ADDS 메시지를 전송하기 위한 목적지 애플리케이션 ID로서 이용될 수 없다. 전송 엔티티는 또한, 예약된 애플리케이션 식별자와 함께 어드레싱 상세사항을 엔드 노드 ADDS 클라이언트(324)에 제공해야 한다.

일부 애플리케이션은 이러한 예약된 애플리케이션 ID를 이용할 수 있고, 엔드 노드에 대한 디폴트 ADDS 메시지 핸들링 애플리케이션으로서 동작할 수 있다. 예약된 앱 ID는 애플리케이션 검색 등의 일부 용도로 지정될 수 있다. 예를 들어, M2M 디바이스가 부팅될 때, 그 디바이스에서 실행 중인 M2M 애플리케이션은 통신할 필요가 있는 SCS 애플리케이션 ID를 알지 못할 수 있지만, SCS FQDN(Fully Qualified Domain Name)은 이용가능할 수 있다. M2M 디바이스 애플리케이션은 메시지를 수신하는 SCS 상의 예약된 애플리케이션에 ADDS 메시지를 전송하고 SCS의 애플리케이션 상세사항을 요청측 M2M 애플리케이션에 전송할 수 있다. 또 다른 예에서, M2M 디바이스 애플리케이션이 ADDS 엔티티(322)에 등록하고 애플리케이션 ID를 획득하고 이 애플리케이션 ID를 SCS에 전달하기를 원할 때, M2M 디바이스 애플리케이션은 그 상세사항을 ADDS 메시지로서, M2M 디바이스 애플리케이션의 ADDS 애플리케이션 ID를 학습하기로 마킹된 SCS 상의 예약된 애플리케이션에 전송할 수 있다.

애플리케이션 이동성

본 실시예에서, ADDS 엔티티(322)는 애플리케이션이(ADDS 서비스를 제공하는) 네트워크에 액세스하는 모드를 이동시키거나 변경하고 ADDS 서비스를 이용하여 그 통신을 여전히 보유하는 것을 허용할 수 있다. 여기서 사용될 때, 애플리케이션 이동성이란 애플리케이션이 네트워크에 접속되는 방식의 변경을 말한다.

예를 들어, 애플리케이션이 실행 중인 엔드 노드는, EPC와 접속하거나 상이한 3GPP 가입(예를 들어, 상이한 3GPP 모뎀 또는 상이한 SIM 카드)을 이용하기 위해, Wi-Fi 또는 WiMAX 등의 상이한 액세스 기술을 이용할 수 있다. M2M 애플리케이션의 경우, 애플리케이션을 호스팅하는 M2M 디바이스는 3GPP 네트워크를 통해 M2M 서버에 접속하는 상이한 M2M GW에 의해 서빙되는 또 다른 영역으로 이동할 수 있다.

실시예에서, ADDS 서비스는, 애플리케이션이 애플리케이션 이동성 후에 자신의 애플리케이션 ID를 유지하는 것을 허용함으로써 애플리케이션 이동성을 가능하게 할 수 있다. ADDS 엔티티(322)가 애플리케이션 ID를 할당할 때, ADDS 엔티티(322)는 또한 보안 토큰을 제공할 수 있다. 애플리케이션이 코어 네트워크와의 접속을 위해 이용하는 ADDS 클라이언트(324)에서의 변화가 있는 애플리케이션 이동성 동안에, 애플리케이션과의 통신에 이용될 새로운 ADDS 클라이언트(324)의 어드레싱 정보를 업데이트하기 위해 애플리케이션 재등록이 수행될 수 있다. 애플리케이션은 이전 애플리케이션 식별자의 재할당을 요청하고 보안 토큰을 제공할 수 있다. 그 다음, ADDS 엔티티(322)는 보안 토큰을 검증하고, 동일한 애플리케이션 ID를 재할당하며, 그 맵핑 테이블을 새로운 ADDS 클라이언트/엔드 노드의 상세사항으로 업데이트할 수 있다.

저장 및 포워드

또 다른 실시예에서, ADDS 서비스는 저장 및 포워드 기능을 제공할 수 있다. 저장 및 포워드 기능은, 목적지 애플리케이션에 의도된 메시지가 ADDS 엔티티(322)에 저장된 다음 나중에 중계되는 메커니즘을 제공한다. ADDS 엔티티의 메시지 저장 결정은 다음과 같은 기준에 의존할 수 있다:

(1) 애플리케이션 특성 - 애플리케이션이 통신 지연에 대해 관대한지의 여부.

(3) 애플리케이션 가용성 - 목적지 애플리케이션은 ADDS 메시지를 수신하지 못할 수 있다. 이것은 실행 중이 아니거나 ADDS로부터 일시적으로 등록취소되었을 수 있다.

(3) 애플리케이션 통보 - 애플리케이션은 ADDS 엔티티(322)에게 인입 ADDS 메시지를 저장하고 메시지 표시만을 전송하도록 통보할 수 있다. 추가 피쳐로서, ADDS 엔티티(322)는, 애플리케이션이, 소정 크기 이상의 메시지는 나중에 전달하기 위해 저장되어야 하는 반면 크기 제한 아래의 메시지는 즉시 전송되도록 명시할 수 있게 할 수 있다.

(4) 엔드 노드 특성 - 엔드 노드는 하루의 명시된 기간 동안에만 데이터 통신에 이용가능할 수 있다. 예를 들어, UE는, UE가 하루 중 소정 기간에만 통신에 이용가능하게 하는 소정의 M2M 피쳐에 가입했을 수 있다.

(5) 엔드 노드 도달가능성 - 엔드 노드는 데이터 통신을 위해 이용가능/도달가능하지 않을 수도 있다. 이것은 네트워크로부터 분리되었거나 무선 커버리지 영역에 있지 않을 수도 있다.

(6) 네트워크 상태 - 네트워크 노드는 과부하 상태에 있거나, 네트워크 노드는 일시적으로 다운되거나 유지보수 중일 수 있다.

(7) 가입 정보 - HSS 116/UDR 352으로부터의 가입 정보.

(8) 정책 규칙 - PCRF 334로부터의 정책 및 과금 규칙.

경로 선택

ADDS 클라이언트(324) 및 ADDS 엔티티(322)의 두드러진 기능들 중 하나는 그들의 트랜스포트 메커니즘/경로 선택 기능이다. 이 피쳐는 ADDS 메시지를 트랜스포트하기 위해 3GPP 네트워크에서 이용할 수 있는 다양한 기존의 트랜스포트 메커니즘을 활용한다. 예를 들어, 한 실시예에서, ADDS 클라이언트와 네트워크 사이의 ADDS 메시지는 다음과 같은 기존의 3GPP 트랜스포트 메커니즘들 중 선택된 하나를 이용하여 트랜스포트될 수 있다: SMS(Short Message Service), NAS(Non-Access Stratum), USSD(Unstructured Supplementary Service Data) 또는 사용자 평면. 상기 트랜스포트 방법들 및 이용된 프로토콜 스택들을 통해 ADDS 메시지를 트랜스포트하기 위한 방법이 이하에서 더 상세하게 설명된다.

다른 실시예에서, ADDS 서비스는 또한, 그룹 통신을 위해 3GPP 네트워크에서 이용가능한 브로드캐스팅 및 멀티캐스팅 메커니즘을 이용할 수 있다. 예를 들어, ADDS 메시지가 복수의 상이한 엔드 노드들에 전송될 예정이라면, 다음과 같은 메커니즘들 중 선택된 하나가 채용될 수 있다 : Cell Broadcast Service(CBS); 멀티미디어 브로드캐스트 멀티캐스트 서비스(MBMS); 진보된 멀티미디어 브로드캐스트 멀티캐스트 서비스(eMBMS), IP 멀티캐스팅 등.

한 실시예에서, 주어진 ADDS 메시지를 트랜스포트하기 위해 이용될 트랜스포트 메커니즘/경로를 선택하는 데 있어서 ADDS 클라이언트(324) 또는 ADDS 엔티티(322)에 의해 다음과 같은 기준이 이용될 수 있다 :

(1) 메시지 길이 - 메시지 길이는 선택할 트랜스포트 메커니즘/경로의 결정에 있어서 중요한 요인이 될 수 있다. 예를 들어, 메시지 크기가 작다면, SMS 경로가 이용될 수 있고, 대안으로서, 메시지 크기가 매우 크다면, 사용자 평면 경로가 이용될 수 있다.

(2) 메시지 특성 및 애플리케이션 특성 - 소스 애플리케이션(즉, 메시지 전송을 요청하는 애플리케이션)은 애플리케이션의 특성 뿐만 아니라 메시지의 특성을 제공할 수 있고, 이러한 특성들은 경로 선택에 있어서 ADDS 클라이언트(324) 또는 ADDS 엔티티(322)에 의해 고려될 수 있다. 예를 들어, 메시지 레이트, 서비스 품질(QoS) 요건, 메시지의 중요성(예를 들어, 높은 중요도 또는 낮은 중요도), 이용가능한 식별자 등과 같은 애플리케이션 또는 메시지 특성은, 적절한 트랜스포트 메커니즘/경로를 결정하는 데 있어서, ADDS 클라이언트(324) 또는 ADDS 엔티티(322)에 의해 이용될 수 있다.

(4) 엔드 노드 능력 및 가용성 - 엔드 노드는 일부 트랜스포트 경로만을 지원할 수도 있다. 예를 들어, LTE UE는 USSD 트랜스포트 메커니즘을 지원하지 않을 수 있으며, SCS는 IP 경로(즉, 사용자 평면) 통신만을 지원할 수도 있다. 이러한 제약은 주어진 ADDS 메시지에 대한 트랜스포트 메커니즘/경로를 선택할 때 고려될 것이다.

(5) 코어 네트워크 노드 가용성 및 네트워크 상태 - 네트워크 내의 ADDS 엔티티(322)는, (MME(114), MSC(238), PGW(112) 등의) 3GPP 코어 네트워크 노드의 가용성에 기초하여 트랜스포트 메커니즘/경로를 선택할 수 있다. 일부 실시예에서, ADDS 엔티티(322)는, 이들 트랜스포트 메커니즘을 제공하는 코어 네트워크 엔티티/인터페이스가 현재 과부하임을 식별하는 경우, 하나 이상의 엔드 노드의 ADDS 클라이언트(324)에게, 소정의 트랜스포트 메커니즘을 이용하지 말 것을 통보할 수 있다.

(6) 가입 정보 - HSS(116)/UDR(352)로부터의 가입 정보는 ADDS 서비스를 제한된 개수의 가용 트랜스포트 메커니즘/경로의 이용으로 제한할 수 있다.

(7) 정책 정보 - 마지막으로, (OCS(330), OFCS(332) 및 PCRF(334)를 포함하는) 코어 네트워크의 정책 및 과금 제어(PCC; Policy and Charging Control) 기능으로부터의 정책 및 과금 정보는, ADDS 메시지 전송을 위해 선택되는 경로를 동적으로 제어하는 데 이용될 수 있다.

트랜스포트 메커니즘/경로 선택을 위한 이들 7개의 기준들 중 하나 이상이 다양한 실시예에서 채용될 수 있지만, ADDS 서비스는 이러한 기준들만의 이용으로 제한되지 않는다는 것이 이해될 것이다. 오히려, 적절한 경로의 선택을 보조할 수 있는 임의의 기준이 채용될 수 있다. 많은 실시예에서, 네트워크 오퍼레이터는 네트워크의 토폴로지 및 현재의 네트워크 상태에 기초하여 경로 선택 정책을 결정할 것이다.

한 예에서, "메시지 특성 및 애플리케이션 특성"이, 애플리케이션이 높은 지연을 용인하고, 낮은 메시지 레이트를 가지며, 메시지가 중요도가 낮고 비교적 짧은 "메시지 길이"를 나타내는 애플리케이션이 있을 수 있다. 네트워크 오퍼레이터는, SMS가 낮은 레이턴시를 요구하지 않는 소량의 데이터 패킷에 매우 적합하기 때문에, 이 애플리케이션에 대해 SMS 트랜스포트 메커니즘이 선택되도록 ADDS 트랜스포트 메커니즘/경로 선택 정책을 구성할 수 있다. 대안으로서, 네트워크 오퍼레이터는 추가의 SMS 트래픽을 생성하기를 원하지 않는다고 결정할 수 있고, 다시 한번, 데이터 패킷들이 작고 빈번하지 않기 때문에, 이 애플리케이션에 대해 NAS 또는 RRC 등의 일부 제어 평면 트랜스포트 메커니즘이 선택되도록 정책을 구성할 수 있다. 역시 또 다른 대안에서, 네트워크 오퍼레이터는, SMS, NAS 또는 RRC 등의 제어 평면 트랜스포트 메커니즘이 그 순간에 특히 혼잡하다는 것을 ADDS 클라이언트(324) 및/또는 ADDS 엔티티(322)에게 표시할 수 있으며, 그 결과, 이 메시지에 대해 이용할 트랜스포트 메커니즘으로서 사용자 평면이 선택된다.

또 다른 예에서, "메시지 특성 및 애플리케이션 특성"이 애플리케이션 데이터 경로가 높은 지연을 용인하지 않고, 낮은 메시지 레이트를 가지며, 중요도가 낮고 "메시지 길이"가 비교적 짧은 애플리케이션이 있을 수 있다. 네트워크 오퍼레이터는, SMS 메시징이 낮은 전달 레이턴시를 보장하지 않기 때문에, 이 애플리케이션에 대해 SMS가 선택되지 않도록 ADDS 트랜스포트 메커니즘/경로 선택 정책을 구성할 수 있다.

역시 또 다른 예에서, "메시지 특성 및 애플리케이션 특성"이 애플리케이션 데이터 경로가 높은 지연을 용인하고, 낮은 메시지 레이트를 가지며, 중요도가 낮고 "메시지 길이"가 비교적 긴 애플리케이션이 있을 수 있다. 네트워크 오퍼레이터는, 비교적 큰 메시지 크기는 많은 제어 평면 트래픽을 생성하기 때문에, 이 애플리케이션에 대해 SMS, NSA 및 RRC 등의 제어 평면 트랜스포트 메커니즘이 선택되지 않도록 ADDS 트랜스포트 메커니즘/경로 선택 정책을 구성할 수 있다. 따라서, 네트워크 오퍼레이터의 정책은 이 애플리케이션에 대해 사용자 평면이 선택되어 한다고 지시할 수 있다.

ADDS 클라이언트

전술된 바와 같이, 한 실시예에서, ADDS 클라이언트(324)는, UE, SCS, 또는 AS의 메모리에 저장될 수 있고 그 디바이스의 프로세서 상에서 실행될 수 있는 논리적 엔티티(예를 들어, 소프트웨어)를 포함한다. 그러나, 다른 실시예들에서, ADDS 클라이언트(324)는 완전히 하드웨어로 또는 하드웨어와 소프트웨어의 임의의 조합으로 구현될 수도 있다. ADDS 클라이언트(324)는, 네트워크 내의 ADDS 기능(예를 들어, ADDS 엔티티(322))과 인터페이스하여 엔드 노드 상의 애플리케이션들이 서로 통신할 수 있게 한다. 데이터 통신을 위해 ADDS를 요구하는 애플리케이션은 엔드 노드 상의 ADDS 클라이언트(324)에 결속(bind)될 수 있다. 한 실시예에서, ADDS 클라이언트(324)는 다음 기능들을 제공한다 :

(1) 네트워크 ADDS 엔티티(322)에 애플리케이션을 등록하고, 애플리케이션 ID를 획득하고, 각각의 애플리케이션으로 애플리케이션 ID의 맵핑을 유지하고, ADDS 서비스와 관련된 애플리케이션 상태를 유지하는 것.

(2) 애플리케이션 통신의 특성에 따른 애플리케이션 데이터의 전송. 이것은 트랜스포트 메커니즘/경로(예를 들어, NAS, SMS, UDDS, 또는 사용자 평면) 및 데이터를 전송할 시간, 및 애플리케이션 데이터 버퍼링의 선택을 포함한다.

(3) 기저 데이터 트랜스포트 방법 및 기타 ADDS 절차로부터 애플리케이션 추출.

(4) 필요한 경우 애플리케이션 데이터 암호화.

(5) ADDS 프로토콜 헤더의 인코딩 및 암호해독.

(6) 애플리케이션에 API를 제공.

본 실시예에서, 애플리케이션은 AD2 인터페이스를 통해 ADDS 클라이언트(324)와 결속된다. 애플리케이션 및 ADDS 클라이언트가 상이한 물리적 엔티티들 내에 있거나(예를 들어, 디바이스(314)의 App1은 도 3의 UE(312) 상의 ADDS 클라이언트(324)와 결속됨), 또는 동일한 물리적 디바이스에 통합되는(예를 들어, 도 3의 UE(312) 상의 App3 및 App4) 것이 가능하다.

도 5는, ADDS 클라이언트(324) 및 애플리케이션들(예를 들어, 애플리케이션 #1, 애플리케이션 #2 및 애플리케이션 #3)이 동일한 엔드 노드(500)에 존재할 때 ADDS 클라이언트(324)의 아키텍쳐의 한 실시예를 나타낸다. 엔드 노드(500)는, (도 1 내지 도 4의 UE(104, 214, 324 및 318), SCS(306), AS(310) 및 SCS 또는 AS(340) 등의) UE를 포함할 수 있다.

도시된 바와 같이, 호스트 엔드 노드(500) 내의 애플리케이션은 ADDS 클라이언트(324)와 통신하기 위해 AD2 인터페이스를 이용한다. 한 실시예에서, 이 인터페이스는 애플리케이션이 ADDS 서비스를 이용할 수 있게 하기 위해 ADDS 클라이언트에 의해 제공된 API 세트(502)를 포함할 수 있다. 애플리케이션은 이들 API(502)를 이용하여 ADDS 엔티티(322)에 자신을 등록하고 애플리케이션 ID를 획득할 수 있다. 애플리케이션은 또한, 상이한 통신 요건들에 기초하여, 필요하다면, 상이한 ADDS 소켓들(미도시)을 생성할 수 있다. 예를 들어, 하나의 소켓은 메시지의 즉각적인 전달에 이용될 수 있고, 또 하나의 소켓은 지연된 전달에 이용될 수 있다. 한 실시예에서, ADDS 소켓을 개방하고, 소켓을 통해 데이터를 송수신하며, 애플리케이션 특성으로 소켓을 구성하기 위해 API가 제공된다. ADDS 클라이언트(324)는 소켓의 특성 및 애플리케이션 식별자와의 연관을 유지(즉, 엔드 노드(500)의 메모리에 저장)한다. 한 실시예에서, API(502)는 다음과 같은 것들을 포함한다 :

addsRegister()

애플리케이션에 의해 저장될 애플리케이션 식별자와 보안 토큰을 반환한다. 애플리케이션은 또한, 이용될 특정 ID 또는 예약된 애플리케이션 ID를 요청할 수 있다.

addsOpenSocket()

소켓을 식별하는 소켓형 파일 기술자(descriptor)를 반환한다. 이 파일 기술자는 ADDS 메시지를 전송하는 데 이용되어야 한다.

addsSockOptions()

지연된 전달, 신뢰성있는 전달 등과 같은 통신 특성들로 ADDS 클라이언트를 구성하기 위해 애플리케이션에 의해 이용된다.

addsSend()

ADDS를 이용하여 애플리케이션 데이터를 전송한다.

addsCloseSocket()

ADDS 소켓을 닫는다.

addsDataQuery()

네트워크로부터 전달될 보류 중인 메시지를 체크한다.

addsReceive()

애플리케이션 데이터를 판독한다. 메시지를 판독하기 위해 소켓 기술자가 필요하지 않다.

addsEventSubscription()

다른 애플리케이션의 (등록 취소와 같은) 일부 이벤트에 대해서 네트워크 ADDS 엔티티에 등록한다.

addsNotificationCallbackRegister()

이루어진 가입에 기초하여 네트워크로부터 통보가 있을 때 호출할 콜백(call-back) 함수를 등록한다.

addsDeregister()

애플리케이션을 등록취소하고 애플리케이션 ID를 해제한다.

더 도시된 바와 같이, ADDS 클라이언트(324)는 엔드 노드(500)의 네트워크 드라이버(들)와 인터페이스하여 데이터를 전송/수신하고 네트워크 트랜스포트 경로를 학습 및 구성하기 위해 그들의 서비스를 이용한다. 예를 들어, UE의 경우, ADDS 클라이언트는, ADDS 데이터를 송/수신하고 MT(Mobile Termination)의 능력을 검색하며 MT를 구성하기 위해 네트워크/모뎀 드라이버를 이용하여 MT와 인터페이스할 수 있다.

(3GPP TS 27.007에 기술된 바와 같이) TE(예를 들어, 컴퓨터) 및 TA에 의해 인터페이스되는 MT를 포함하는 추상 아키텍쳐가 UE에서 채용되는 한 실시예에서, TE와 MT 사이의 'R' 인터페이스는 다음과 같은 새로운 AT 명령들로 업데이트되어 ADDS 기능을 가능하게 하는 다음과 같은 기능들을 수행할 수 있다:

(1) ADDS 구성. 이 기능은 MT에게 ADDS 클라이언트의 존재에 대해 통보하고 MT가 네트워크로부터 ADDS 엔티티 상세사항을 요청하게 하도록 수행될 수 있다. 이 명령을 이용하여 등록될 수 있는 ADDS 클라이언트 정보는, MT가 제어 평면을 통해(NAS를 통해) 데이터를 수신할 때 ADDS 클라이언트에 데이터를 전달하기 위해 MT에 의해 이용될 수 있다.

(2) ADDS 정보 회수. 이 기능은 후술되는 바와 같이 MT가 네트워크로부터 수신한 ADDS 연락 정보 상세사항을 회수하는 데 이용될 수 있다.

(3) NAS를 통한 데이터. 이 기능은, 데이터가 제어 평면(예를 들어, NAS)을 통해 전송되어야 한다는 것을 ADDS 클라이언트가 MT에게 통보하게 하는 데 이용될 수 있다.

도 6은, ADDS 클라이언트(324)가, ADDS 클라이언트(324)를 호스팅하는 엔드 노드(500')와는 상이한 물리적 디바이스(520) 상에서 실행 중인 애플리케이션(애플리케이션 #1, #2 및 #3)과 인터페이스하는, ADDS 클라이언트(324)의 아키텍쳐의 또 다른 실시예를 나타낸다. 예를 들어, 이 아키텍쳐는, M2M 애플리케이션이 M2M 게이트웨이에 접속된 디바이스 상에서 실행되고, 게이트웨이는 3GPP 네트워크에 접속된 3GPP UE인, M2M 시나리오에서 이용될 수 있다. 이 아키텍쳐에서, AD2 인터페이스는, 엔드 노드(500')와 애플리케이션이 존재하는 디바이스 사이에서 이용되는 네트워크에 의존할 것이다. 예를 들어, M2M 시나리오에서, 이 네트워크는 ZigBee, 6LoWPAN, Wi-Fi 등에 기초할 수 있다.

ADDS 광고

이 섹션은, ADDS 서비스에 의해 제공되는 서비스들과 ADDS 엔티티(322)에 관해 UE 및 SCS에게 인지시키는 방법을 설명한다. ADDS 광고의 목적은, 네트워크가 ADDS 기능을 지원한다는 것을 UE 및 SCS에게 인지시키고, 지원되는 트랜스포트 방법/프로토콜, 애플리케이션 페이로드의 크기 등의 ADDS 엔티티의 능력을 제공하며, IP 주소, MSISDN, FQDN 등의 ADDS 엔티티(322)의 연락 상세정보를 제공하는 것이다. 일부 실시예에서, SCS 또는 AS등의 외부 노드 상의 ADDS 클라이언트에 대한 UE 상의 클라이언트로의 ADDS 광고에 대해 상이한 방법들이 이용될 수 있다.

UE로의 ADDS 광고

이하의 서브섹션들은 UE들에 대한 ADDS 광고에 이용될 수 있는 다양한 방법들을 설명한다. 이용되는 방법의 선택은, 배치되는 ADDS 아키텍쳐(즉, ADDS가 오퍼레이터 수준 또는 PDN 수준에서 구현되는지 또는 ADDS가 서비스 영역 내에 있는지)와 엔드 디바이스의 액세스 타입(즉, 디바이스가 ADDS 엔티티에 액세스하기 위해 3GPP 액세스를 이용하는지 또는 비-3GPP 액세스를 이용하는지)에 의존한다.

부착 방법

한 실시예에서, UE에 ADDS를 광고하기 위한 방법은, ADDS 상세사항을 UE에 제공하기 위해 기존의 3GPP 부착 수락 메시지를 채용한다. 특히, 3GPP UE/MS(예를 들어, 도 2 및 도 4a 내지 도 4e의 UE(214))가 3GPP TS 23.401 또는 3GPP TS 23.060에서 언급된 부착(Attach) 절차에 따라 네트워크에 부착할 때, UE/MS(214)는 부착 요청 메시지에서 ADDS 상세사항을 요청할 수 있다. MME(114)는 ADDS 정보로 구성될 수 있거나 HSS(116) 또는 HLR(미도시)에 저장된 UE의 가입 정보로부터 그것을 회수할 수 있다. MME(114)는 부착 수락 메시지에서 ADDS 상세사항을 UE에 전달할 수 있다. 도 7은 기존의 3GPP LTE UE 부착 절차의 맥락에서 이 방법을 나타낸다. 이 실시예에서, 단계들 1, 2, 8, 11, 16, 17 및 18에서 ADDS 광고를 수행하기 위해 수정된 메시지가 이용된다. 나머지 단계들은 기존의 3GPP 부착 절차와 실질적으로 동일하다. 도 7은 LTE 네트워크에서의 부착 절차를 나타내고 있지만, ADDS 광고를 수행하기 위해 UMTS, GPRS 또는 다른 타입의 네트워크에서의 부착 절차도 유사한 방식으로 강화될 수 있다는 점에 유의한다.

도 7의 부착 절차의 단계들 ―특히 ADDS 광고를 지원하기 위해 본 실시예에서 수정된 단계들 ―을 참조하면, 단계들 1-2에서, UE(214)가 코어 네트워크에 부착 요청을 전송할 때, UE가 네트워크에 의해 지원되는 ADDS 상세사항(있는 경우)에 대해 알기를 원하는 것을 나타내기 위해 정보 요소(IE)가 메시지에 추가될 수 있다. 'UE 네트워크 능력' IE는 또한, UE가 ADDS 기능을 지원하는지에 대한 표시를 포함하도록 강화될 수 있다.

단계 8에서, ULR 메시지는, MME(114)가 UE에 의해 가입된 ADDS 정보를 필요로 한다는 것을 나타내는 플래그를 포함하도록 업데이트될 수 있다.

단계 11에서, HSS는 ULA 메시지에 ADDS 상세사항을 포함할 수 있다. 3GPP TS 29.272에 정의된 '가입 데이터' 다이어미터(Diameter) AVP는 ADDS 상세사항을 포함하도록 수정될 수 있다. 상세사항으로서는, 지원되는 ADDS 피쳐, ADDS 트랜스포트 경로 및 관련 정보가 포함될 수 있다. 포함될 수 있는 상세사항의 예가 아래의 표 1에 도시되어 있다.

단계 17에서, MME(114)가 부착 수락(Attach Accept) 메시지를 전송할 때, 이것은 표 1에 열거된 ADDS 정보를 포함할 수 있다. 단계 18에서, eNB(106)로부터의 RRC 재구성(RRC Reconfiguration) 메시지는 수정되지 않을 수 있지만, 피기백된(piggybacked) NAS 부착 수락 메시지는 ADDS 정보를 포함할 수 있다. 부착 절차의 다른 모든 단계들은 영향을 받지 않으며 3GPP TS 23.401에 정의된 대로 수행될 수 있다.

ADDS 정보 요청 절차 방법

도 8은 한 실시예에 따른 ADDS 광고를 위한 또 다른 방법을 나타낸다. 이 방법에서, UE(214)는, 독립형 ADDS 정보 요청을 실행함으로써 ADDS 기능에 관한 정보를 요청할 수 있다. 구체적으로는, 도 8에 도시된 바와 같이, 단계 1에서, UE(214)는, ADDS 정보를 요청하는 NAS EMM 메시지를 MME(114)에 전송한다. 단계 2에서, MME(114)는 ULR 메시지를 HSS(116)에 전송하여 ADDS 정보를 요청한다. 한 실시예에서, 이 단계는 선택사항이며, MME(114)는 MME(114)가 아직 ADDS 정보를 갖고 있지 않은 경우에 이 요청을 전송할 수 있다. 단계 3에서, HSS(116)는 전술된 도 7에 나타낸 방법의 단계 11에서 설명된 것과 동일한 방식으로 ULA 메시지를 전송한다. 단계 4에서, MME(114)는 NAS EMM 메시지를 전송하여 UE(214)를 ADDS 정보로 업데이트한다. 다른 실시예들에서, 서빙 GPRS 지원 노드(SGSN)가 ADDS 정보 요청에 응답할 수 있는 GPRS 및 UMTS 네트워크에서 유사한 접근법이 이용될 수 있다는 점에 유의한다.

특별 APN 방법

도 9는 한 실시예에 따른 ADDS 광고를 위한 역시 또 다른 방법을 나타낸다. 일반적으로 네트워크 오퍼레이터는 전적으로 ADDS 기능을 위해 APN을 마킹할 수 있다. ADDS를 이용하고자 하는 UE는 이 특별 APN으로의 PDN 접속을 요청할 수 있다. 코어 네트워크는 UE가 ADDS 정보를 요구한다고 추론할 수 있고, 기존의 3GPP PDN 접속 수락(Connectivity Accept) 메시지에서 상세사항을 UE에 전달할 수 있다. 이 방법은, 예를 들어 도 4a 및 도 4b에 나타낸 바와 같이, PGW를 ADDS 엔티티에 접속하기 위해 '사설 PDN'이 이용될 때 적용될 수 있다. 특별 APN으로의 PDN 접속은, UE가 네트워크 오퍼레이터의 사설 PDN을 통해 ADDS와 통신하는 것을 허용할 수 있다.

도 9의 단계들은 이 방법의 한 실시예를 나타낸다. APN 명칭을 제공하는 것 대신에, UE(214)는 ADDS에 액세스하기 위한 PDN 접속을 형성하기를 원한다는 표시를 포함할 수도 있다는 점에 유의한다. MME(114)/HSS(116)는, ADDS를 액세스할 수 있는 사설 PDN에 접속하기 위해 이용되어야 하는 APN을 결정할 수 있다.

도 9를 참조하면, 단계 1에서, UE(214)는 3GPP 'PDN Connectivity Request' 메시지 등의 NAS 메시지에서 특별 APN 또는 플래그(새로운 IE)를 제공하여 ADDS를 필요로 한다는 것을 나타낼 수 있다. 단계 2 및 3에서, 특별 APN이 PGW(112)에 전달된다. 단계 4a에서, PGW(112)는 선택사항으로서 ADDS 정보 조회 요청(information query request)을 전송함으로써 ADDS로부터 최신 정보를 회수할 수 있다. ADDS는 ADDS를 이용하는 UE(214)의 인가 상세사항에 대해 HSS(116)(또는 SPR 또는 UDR)에게 체크한 다음 상세사항을 PGW(112)에 제공할 수 있다.

단계 5에서, PGW(112)는 (표 1에 열거된) ADDS 정보를 기존의 '세션 생성 응답(Create Session Response)' 메시지의 3GPP PCO IE에 포함시켜 그것을 UE(214)에 전송할 수 있다. 단계 6, 7 및 8에서, PGW(112)로부터의 수정된 PCO IE는 UE(214)에 전달된다. 이 실시예에서, 이 PDN 접속 절차의 모든 다른 단계들은 영향을 받지 않으며 실질적으로 3GPP TS 23.401에 정의된 대로 유지된다.

PDN 접속 방법

ADDS 광고를 위해 채용될 수 있는 또 다른 방법은 도 9에 나타낸 방법과 유사하지만, ADDS(322)와 PGW(112) 사이의 통신을 위해서는 특별 PDN이 이용되지 않는다. 이 방법에서, UE(214)는 임의의 PDN에 접속할 수 있고, 그 PDN에 대해 이용될 ADDS 기능을 요청할 수 있다. 'PDN 접속 요청(PDN Connectivity Request)'에서 특별 APN을 이용하는 것 대신에, UE는 새로운 IE(예를 들어, 플래그)를 'PDN 접속 요청'에 포함시켜 ADDS 상세사항이 요청되었다는 것을 나타낼 수 있다. PGW(112)는 '세션 생성 응답(Create Session Response)' 메시지의 PCO IE에서 ADDS 상세사항으로 응답할 수 있다. 이 방법에서, 콜 흐름은 도 9와 유사할 것이다.

사용자/오퍼레이터 제공

ADDS 광고를 위한 또 다른 방법은, 네트워크 오퍼레이터에 의해 공개되거나 네트워크 오퍼레이터로부터 획득될 수 있는 값에 따라 ADDS 정보를 디바이스 상에 수동으로 제공하는 디바이스의 사용자에게 의존할 수 있다. ADDS 기능을 제공하는 네트워크 오퍼레이터는, 기존의 OMA(Open Mobile Alliance) 디바이스 관리(DM) 또는 USIM(Universal Subscriber Identity Module) OTA(Over-The-Air) 업데이트 방법을 이용하여 ADDS 정보를 디바이스에 동적으로 제공할 수 있다.

SCS로의 ADDS 광고

이 섹션은 SCS가 코어 네트워크에 의해 제공되는 ADDS 상세사항을 인지할 수 있는 방법을 설명한다.

Tsp 인터페이스 방법

도 10은 SCS에 대한 ADDS 광고에 대해 Tsp 인터페이스가 이용되는 방법의 한 실시예를 나타낸다. 이 실시예에서, SCS(340)는 단계 1에 도시된 바와 같이 Tsp 인터페이스를 통해 ADDS 정보 요청을 전송함으로써 ADDS 정보를 요청할 수 있다. 단계 2에서, MTC-IWF(210)는, 단계 3에 도시된 바와 같이, ADDS를 이용하고 ADDS 정보를 SCS에 제공하기 위한 SCS(340)의 인가에 대해 HSS(116)에게 체크할 수 있다. ADDS와 SCS 사이의 트랜스포트 메커니즘/경로 옵션의 수는 제한될 수 있기 때문에, SCS에 제공되는 ADDS 상세사항은 UE에 제공되는 ADDS 상세사항과는 달리 제한된 정보를 가질 수 있다. SCS에 제공되는 ADDS 상세사항의 예가 이하의 표 2에 열거되어 있다.

Mh / Rx 인터페이스 방법

SCS에 대한 ADDS 광고를 위한 또 다른 방법에 따르면, SCS(340)는 또한, 기존의 3GPP Mh 또는 Rx 인터페이스를 통해 표 2에 열거된 ADDS 정보를 회수할 수 있다. 이 방법에서, ADDS 정보는 HSS(116) 또는 PCRF(334)에 제공되어 SCS/AS(340)가 Mh 또는 Rx 인터페이스를 통해 이 정보를 회수할 수 있게 한다. HSS 및 PCRF에서의 이러한 정보의 제공은, 네트워크 오퍼레이터에 의해, 또는 ADDS가 HSS(116) 및 PCRF(340)와 함께 갖는 AD6 및 AD3 인터페이스를 통해 ADDS 엔티티(322)에 의해 동적으로 이루어질 수 있다.

다른 실시예에서, SCS상의 ADDS 정보는 M2M 네트워크의 오퍼레이터에 의해 수동으로 제공될 수 있다.

ADDS 프로토콜 스택

전술된 바와 같이, ADDS 서비스의 중요한 피쳐는, 애플리케이션 사이에서 ADDS 데이터 메시지를 운반하기 위해 코어 네트워크에서 이용가능한 복수의 상이한 트랜스포트 메커니즘/경로 중 하나를 선택하는 것이다. 네트워크 내의 ADDS 클라이언트(324) 및 ADDS 엔티티(322)는, 전술된 트랜스포트 경로 선택 기준에 따라 트랜스포트 경로를 선택한다. 데이터 메시지를 전송하는 프로세스는 도 15와 관련하여 이하에서 더 상세하게 설명된다. SCS 또는 AS(340) 등의, 네트워크측 엔드 노드 상의 ADDS 클라이언트(322)와 ADDS 엔티티(322) 사이의 통신은, 한 실시예에서, 일반적으로 IP 기반일 수 있다. ADDS 서비스가 이용하는 TCP, UDP 또는 SCTP 등의 트랜스포트 계층은, 메시지의 중요도 및 특정 메시지 또는 애플리케이션에게 신뢰성 있는 트랜스포트 메커니즘이 요구되는지의 여부 등의, 전송되는 메시지의 특성에 의존할 수 있다.

(도 2 내지 도 4의 UE(214, 312 및 318) 등의) UE 등의 액세스측 엔드 노드 상의 ADDS 클라이언트(324)와 ADDS 엔티티(322) 사이의 통신은, 한 실시예에서, NAS, SMS의 사용자 평면 등의, 다른 복수의 이용가능한 트랜스포트 메커니즘들 중 선택된 하나를 통해 수행될 수 있다. 도 11a 내지 도 11d는, 이들 상이한 트랜스포트 메커니즘들 각각에 대해 채택된 프로토콜 스택들 및 이들 상이한 트랜스포트 경로들을 통한 ADDS 메시지의 트랜스포트 방식을 나타낸다.

도 11a는 NAS를 통한 ADDS 메시지 전송을 위한 프로토콜 스택을 도시한다. 이 실시예에서, 이하에서 더 상세히 설명하는 바와 같이 ADDS 헤더 및 페이로드를 포함할 수 있는 ADDS 메시지는 일반 NAS 트랜스포트 메시지로 캡슐화된다. 이 경우에, UPLINK GENERIC NAS TRANSPORT 메시지는 UE(214)로부터 MME(114)로 ADDS 메시지를 운반하는 데 이용될 수 있고, DOWNLINK GENERIC NAS TRANSPORT 메시지는 MME(114)로부터 UE(214)로 메시지를 운반하는 데 이용될 수 있다. 이들 메시지들은 3GPP TS 23.401(섹션 5.6.4 및 섹션 8.2.30)에 설명되어 있다. 또한 이 실시예에서, NAS 트랜스포트 메시지의 일반 메시지 컨테이너 타입 IE는 메시지가 ADDS 메시지임을 표시하기 위해 미사용 필드들 중 하나(예를 들어, "00000011")로 설정될 수 있고, 일반 메시지 컨테이너 IE는 또한, ADDS에 전달될 전체 페이로드를 운반하는 데 이용될 수 있다.

업링크 경로에서, MME(114)는 그 일반 NAS 메시지가 ADDS에 전달되어야한다고 해석하고, 페이로드를 다이어미터(Diameter) 메시지로 변환하고, 이것을 AD5 인터페이스를 통해 ADDS 엔티티(322)에 전송한다. ADDS 엔티티(322)는 메시지 헤더를 해석하고, 목적지 ADDS 애플리케이션 식별자/디바이스 식별자를 추출하고, 메시지를 AD1 인터페이스를 통해 SCS(340)에 전송한다.

다운링크 경로에서, SCS(340)는 MTC 애플리케이션의 애플리케이션 식별자와 ADDS 헤더 및 페이로드 정보를 AD1 인터페이스를 통해 ADDS 엔티티(322)에 제공한다. 메시지 전달을 위해 AD5 전송 경로가 선택되면, ADDS 엔티티(322)는 목적지 애플리케이션 식별자를 이용하고 목적지 애플리케이션이 존재하는 UE(예를 들어, UE(214))의 IMSI를 찾는다. ADDS 엔티티는 데이터를 다이어미터(Diameter) 메시지로 변환하고 이것을 NAS를 통해 메시지가 전송되어야 할 UE의 IMSI와 함께 MME(114)에 전송한다. MME(114)는 다이어미터(Diameter) 메시지를 다운링크 일반 NAS 트랜스포트 메시지로 변환하여 이 메시지를 UE(214)에 전송한다.

도 11b는 사용자 평면을 통한 ADDS 메시지 전송을 위한 프로토콜 스택을 도시한다. 이 경우, ADDS 메시지는 보통의 사용자 평면 IP 패킷으로 트랜스포트되어 GTP 사용자 평면을 통해 전송될 수 있다.

업링크에서, UE(214) 상의 ADDS 클라이언트(324)는 메시지 특성에 기초하여 이용될 전송 프로토콜(예를 들어, TCP, UDP 또는 SCTP)을 선택할 수 있고, ADDS 엔티티(322)의 IP 주소에 어드레싱된 IP 패킷을 전송할 수 있다. 이 IP 패킷은 보통의 사용자 평면을 따를 수 있고 GTP-U 패킷으로 캡슐화되어 eNodeB(106), SGW(110) 및 PGW(112)를 통해 ADDS 엔티티(322)에 전송될 수 있다. ADDS 엔티티(322)는 수신된 메시지를 해석하고, 목적지 ADDS 애플리케이션 식별자/디바이스 식별자를 추출하고, 메시지를 AD1 인터페이스를 통해 SCS(340)에 전송한다.

다운링크 경로에서, SCS(340)는 MTC 애플리케이션의 애플리케이션 식별자와 ADDS 헤더 및 페이로드 정보를 AD1 인터페이스를 통해 ADDS 엔티티(322)에 제공한다. 메시지 전달을 위해 사용자 평면 경로가 선택된다면, ADDS 엔티티(322)는 목적지 애플리케이션 식별자를 이용하고 (ADDS 엔티티(322)에 저장된 맵핑 테이블로부터) 목적지 애플리케이션이 존재하는 UE의 IP 주소를 찾는다. ADDS 엔티티는 이용될 전송 프로토콜(예를 들어, TCP, UDP 또는 SCTP)을 선택하고 UE의 IP 주소에 어드레싱된 IP 패킷을 구축하여 이를 SGi 인터페이스 상에서 PGW(112)에 전송한다.

도 11c는 SMS를 이용한 ADDS 메시지 전송을 위한 프로토콜 스택을 도시한다. 이 실시예에서, ADDS 메시지는 SMS 메시지로서 트랜스포트될 수 있다.

업링크 경로에서, UE는 ADDS 메시지를 SMS TPDU로 캡슐화하고 이것을 모바일 발신 SMS(MO SMS) 메시지로서 트랜스포트한다. 이 실시예에서, SMS 메시지는, TP 목적지 주소(TP-DA)를 ADDS 엔티티(322)의 주소로 설정함으로써 ADDS 엔티티로 어드레싱된다. ADDS 엔티티(322)는 수신된 메시지를 해석하고, 목적지 ADDS 애플리케이션 식별자/디바이스 식별자를 추출하고, 메시지를 AD1 인터페이스를 통해 SCS(340)에 전송한다.

다운링크 경로에서, SCS(340)는 MTC 애플리케이션의 애플리케이션 식별자와 ADDS 헤더 및 페이로드 정보를 AD1 인터페이스를 통해 ADDS(322)에 제공한다. 메시지 전달을 위해 SMS 트랜스포트 메커니즘/경로가 선택된다면, ADDS 엔티티(322)는 발견을 위해 목적지 애플리케이션 식별자를 이용하여 그 저장된 맵핑 테이블로부터 목적지 애플리케이션이 존재하는 UE(214)의 주소(MSISDN)를 찾는다. 이 실시예에서, ADDS(322)는 외부 SME로서 동작하고 SMS-SC(204)에 ADDS 메시지를 전송하여 모바일 종단(MT) SMS로서 트랜스포트된다. SMS-SC(204)와 ADDS 엔티티(322) 사이의 인터페이스는, MTC-IWF(210)와 SMS-SC(204) 사이의 T4 인터페이스와 유사한 다이어미터 프로토콜에 기초할 수 있다. 대안으로서, 단문 피어-투-피어(SMPP), CIMD(Computer Interface to Message Distribution) 또는 범용 컴퓨터 프로토콜/외부 머신 인터페이스(UCP/EMI) 등의 다른 프로토콜이 이용될 수 있다. SMS 메시지는, SG 기준점을 통한 SMS, IMS 네트워크를 통한 SMS, 또는 CS(Circuit Switched) 폴백(fallback)의 이용 등의 가용 방법들 중 임의의 것을 이용하여, UE(214)와 ADDS 엔티티(322) 사이에서 전송될 수 있다.

도 11d는 USSD를 이용한 ADDS 메시지 전송을 위한 프로토콜 스택을 도시한다. 이 경우 ADDS 메시지는 USSD 메시지로서 트랜스포트된다.

업링크 경로에서, UE(214) 내의 USSD 요소는 ADDS 메시지를 USSD 데이터 버스트 메시지(USSD Data Burst Message)로 캡슐화하고 모바일 개시형 USSD로서 트랜스포트한다. USSD 메시지는, ADDS 엔티티(322)에서 USSD 게이트웨이의 USSD 짧은 코드를 설정함으로써 ADDS 엔티티(322)에 어드레싱될 수 있다. ADDS 엔티티(322)는 수신된 메시지를 해석하고, 목적지 ADDS 애플리케이션 식별자/디바이스 식별자를 추출하고, 메시지를 AD1 인터페이스를 통해 SCS(340)에 전송한다.

다운링크 경로에서, SCS(340)는 MTC 애플리케이션의 애플리케이션 식별자와 ADDS 헤더 및 페이로드 정보를 AD1 인터페이스를 통해 ADDS 엔티티(322)에 제공한다. 메시지 전달을 위해 USSD 트랜스포트 메커니즘/경로가 선택된다면, ADDS 엔티티(322)는 목적지 애플리케이션 식별자를 이용하여 자신의 내부 맵핑 테이블로부터 UE(214)의 USSD 코드를 찾는다. 이 실시예에서, ADDS 엔티티(322)는 USSD 게이트웨이로서 동작하고 USSD 요청 메시지 또는 USSD 통보 메시지로 캡슐화된 ADDS 메시지를 MSC(238)에 전송하여 네트워크 개시형 USSD로서 전송되게 한다. MSC(238)와 ADDS 엔티티(322) 내의 USSD 게이트웨이 사이의 인터페이스는, 한 실시예에서, MAP 프로토콜에 기초할 수 있다.

ADDS 프로토콜 및 메시지 포멧

도 11a 내지 도 11d에 나타낸 바와 같이, ADDS 프로토콜은, UE(예를 들어, UE(214)) 또는 SCS(예를 들어, SCS(340)) 상의 ADDS 클라이언트(324)와 네트워크 내의 ADDS 엔티티(322) 사이의 통신에 이용된다. ADDS 프로토콜은 메시지 전달을 위해 선택된 트랜스포트 메커니즘/경로에 기초하여 ADDS 메시지의 분할 및 재조립을 수행할 수 있다. 시퀀스 번호는, 상이한 경로들을 통해 트랜스포트되는 ADDS 메시지들의 재정렬을 가능케하기 위해 ADDS 프로토콜에서 이용될 수 있다.

한 실시예에서, ADDS 메시지들은 공통의 헤더를 가질 수 있고, 트랜스포트 특성, 애플리케이션 특성 등의 ADDS 절차와 관련된 ADDS 제어 정보를 운반할 수 있다. 애플리케이션 데이터는 데이터에 대한 정보를 포함하는 추가 데이터 헤더를 포함함으로써 유사한 방식으로 전달될 수 있다. 데이터 헤더 및 페이로드는 이하에서 더 상세히 설명되는 'ADDS 데이터 전송 요청' 및 'ADDS 데이터 전달' 메시지에만 존재할 수 있다. 도 12는 본 발명의 한 실시예에 따른 ADDS 메시지의 포멧을 나타낸다. 다음은 메시지 포멧의 공통 헤더의 각각의 필드에 대해 설명한다:

● 메시지 타입 : 전송 중인 메시지의 타입을 나타낸다.

● 메시지 길이 : ADDS 메시지의 전체 길이

● 시퀀스 번호 : 전송 측 엔티티에 의해 증가하는 순서로 할당된 번호.

● 세그먼트화 비트 : 메시지가 세그먼트화되어 있는지를 나타낸다.

● 세그먼트 시퀀스 번호 : ADDS 메시지의 개별 세그먼트들의 시퀀스 번호. 이것은 세그먼트화 비트(Segmentation Bits) IE가 '00'으로 설정되지 않은 경우에만 유효하다.

● 체크섬 : 페이로드의 무결성 검사를 위한 체크섬.

● 확장 헤더 정보 : 이것은, 오류 정보, 보안 등과 같은 추가 정보가 운반되어야 하는 경우에 이용될 수 있다.

도 7에 더 도시된 바와 같이, ADDS 공통 헤더 다음에는, 메시지 타입에 따라 0개 이상의 정보 요소(IE)가 후속되고, 그 다음, 전송 중인 데이터에 특유한 헤더가 후속되며, 그 다음, 애플리케이션 페이로드 필드의 애플리케이션 데이터 자체가 후속된다.

다음은, ADDS 서비스의 한 실시예에 따라 전송될 수 있는 ADDS 메시지들의 목록이다. 이들 메시지들의 내용은, 이들을 이용하는 다양한 ADDS 절차에 대한 설명과 관련하여 아래에서 설명된다.

ADDS Application Register Request

ADDS Application Register Response

ADDS Application Event Notification

ADDS Application Event Response

ADDS Application Update Request

ADDS Application Update Response

ADDS Data Transfer Request*

ADDS Data Transfer Accept

ADDS Data Delivery*

ADDS Data Transfer Complete

ADDS Data Notification

ADDS Data Notification Ack

ADDS Data Query

ADDS Data Query Ack

ADDS Data Request

ADDS Event Subscription Request

ADDS Event Subscription Ack

ADDS Application De-Registration Request

ADDS Application De-Registration Response

소정 메시지 타입 옆의 별표("*")는 메시지 타입이 애플리케이션 데이터를 운반할 수 있다는 것을 나타낸다.

ADDS 절차

이 섹션은 그 기능을 제공하기 위하여 ADDS 서비스에 의해 실행될 수 있는 다수의 절차를 설명한다. 이러한 절차로서는, ADDS 애플리케이션 등록, ADDS 업데이트 절차, ADDS 데이터 전송, ADDS 이벤트 가입, 및 ADDS 애플리케이션 등록취소가 포함된다. 다른 실시예에서, 더 많거나 더 적은 수의 절차들이 제공될 수 있다. 이들 절차들 각각은 아래에서 더 자세히 논의된다.

ADDS 애플리케이션 등록

애플리케이션 등록 절차의 목적은 ADDS 기능을 이용할 것을 요구하는 애플리케이션에게 애플리케이션 식별자를 할당하는 것이다. 엔드 노드의 애플리케이션이 ADDS 소켓을 개방하면, ADDS 클라이언트는 'ADDS 애플리케이션 등록' 절차를 시작하여 네트워크 ADDS 엔티티에게 ADDS 애플리케이션 식별자를 애플리케이션에 할당할 것을 요청한다. ADDS 엔티티는 요청 엔드 노드(UE 또는 SCS)의 가입 정보에 대한 및 디바이스 식별자를 IMSI 또는 SCS ID와 같은 내부 식별자로 변환하는 것에 대한 요청을 HSS/UDR에 제출한다. 그 다음, ADDS 엔티티는 애플리케이션 식별자를 할당하고 (여기서는 "디바이스 ID"라고도 하는) 디바이스 식별자(예를 들어, UE ID 또는 SCS ID)와의 애플리케이션 식별자의 맵핑을 유지한다. ADDS 엔티티는 또한, 애플리케이션에 대해 집행할 정책 및 과금 상세사항을 얻기 위해 PCRF에 애플리케이션 상세사항을 제공할 수 있다.

네트워크는, 애플리케이션을 등록하려고 시도하는 엔드 노드에 따라 추가적인 단계들을 수행할 수 있다. 예를 들어, 절차가 UE의 애플리케이션에 의해 개시되었다면, ADDS 엔티티는 대응하는 SCS를 체크/통보하고 UE의 (애플리케이션 타입 및 애플리케이션 ID와 같은) 애플리케이션 상세사항을 제공할 수 있다. 따라서, SCS는 애플리케이션 상세사항을 학습하고 UE와의 향후의 통신을 위해 UE의 애플리케이션 ID를 이용할 수 있다. SCS는 애플리케이션 트래픽에 대한 추가 정책 및 과금 정보를 제공할 수 있다. 예를 들어, SCS는 응답시에 애플리케이션의 지연 용인 시간, 애플리케이션 가용성 시간 등과 같은 애플리케이션 상세사항을 변경할 수 있다. SCS는 또한, 적용될 온라인 또는 오프라인 과금 등의 과금 특성을 제공하고 SCS가 애플리케이션 트래픽에 대해 과금되어야 한다면 상세사항을 후원할 수 있다. 도 13은 한 실시예에 따른 이 절차에 대한 예시적 콜 흐름을 도시한다.

단계 1에서, ADDS 클라이언트(324)는 전술된 ADDS 광고 절차들 중 하나를 통해 네트워크 ADDS 엔티티(322)의 연락 상세사항을 학습한다.

단계 2에서, 애플리케이션은 AD2 인터페이스 API를 이용하여 ADDS 클라이언트(324)에 등록한다.

단계 3에서, ADDS 클라이언트(324)는 'ADDS 애플리케이션 등록 요청'을 ADDS 엔티티(322)에 전송하여 애플리케이션에 대한 애플리케이션 식별자를 요청한다. 이 메시지는 AD1 인터페이스를 통해 전송되며 이 메시지는 이용가능한 트랜스포트 메커니즘들(예를 들어, NAS, SMS, USSD, 사용자 평면) 중 임의의 것을 통해 전송될 수 있다. 한 실시예에서, 다음과 같은 정보가 이 메시지에서 전송된다 :

a. ADDS 메시지 타입(Message Type):

이것은 메시지가 'ADDS 애플리케이션 등록 요청' 메시지임을 나타낸다.

b. 디바이스 타입(Device Type):

이것은 애플리케이션이 실행 중인 엔드 노드가 SCS와 같은 네트워크 엔티티인지 또는 UE인지를 나타내기 위한 것이다.

c. 디바이스 신원(Device Identity):

디바이스를 고유하게 식별하기 위해 네트워크에 의해 이용될 수 있는 디바이스 식별자. 이것은 네트워크에 의해 할당된 식별자이거나 전역적으로 알려진/확인가능한 식별자일 수 있다. 다음은 디바이스 식별에 이용될 수 있는 일부 식별자들이다. 이용되는 식별자는 엔드 노드 타입에 의존한다.

UE의 경우

i. IMSI

ii. MSISDN

iii. GUTI/PTMSI

iv. 네트워크 할당된 IP 주소(UE가 NAT 디바이스 뒤쪽에 있다면 로컬 IP가 아님)

v. M2M 외부 식별자

vi. SIP URI

vii. NAI

네트워크 노드의 경우

i. SCS ID/외부 ID

ii. FQDN

iii. SIP URI

iv. NAI

v. IP 주소

d. 요청된 애플리케이션 식별자

이것은 선택사항적 필드이며 유효한 애플리케이션 식별자를 포함한다. 애플리케이션은 자신에게 할당될 애플리케이션 식별자를 요청할 수 있다. 보통은, 이것은, 애플리케이션이 이전에 등록되어 있고 애플리케이션이 재시작되거나 실패하거나 또 다른 디바이스로 이동한 이후에 동일한 애플리케이션 식별자를 재사용하기를 원하는 경우에 이용될 수 있다. 그러나 이것은 또한, 특정 애플리케이션 ID를 요청하기 위해 이전에 등록되지 않았던 애플리케이션에 의해서도 이용될 수 있다.

e. 보안 토큰

이 필드는, 애플리케이션이 이전에 자신에게 할당되었던 애플리케이션 식별자의 재사용을 요청할 경우에 포함될 수 있다. 이것은, ADDS 엔티티가 이전에 애플리케이션 ID를 애플리케이션에 할당했을 때 ADDS 엔티티에 의해 제공되었던 보안 토큰 값과 동일할 수 있다. 이것은, 어떤 다른 애플리케이션이 소정 애플리케이션인 것처럼 기만하고 있지 않다는 것을 인증하기 위한 것이다. 이것은, 다른 애플리케이션이 또 다른 애플리케이션의 애플리케이션 ID를 잘못 차지하여 그 메시지를 수신하는 것을 피하기 위한 인증 목적을 위한 것이다.

f. 애플리케이션 상세사항

이 필드는 애플리케이션 특성 및 상세사항을 포함한다. 이것은 데이터 스케줄링 및 트랜스포트 메커니즘/경로 선택 목적을 위해 ADDS에 의해 이용될 수 있다.

- 애플리케이션 타입

- 애플리케이션 명칭

- 애플리케이션 인스턴스

- 애플리케이션 특성

○ 지연 용인 - 애플리케이션으로부터의 또는 애플리케이션으로의 메시지가 얼마나 오랫동안 지연될 수 있는가.

○ 애플리케이션 가용성 - 애플리케이션이 이용가능한 기간.

○ 최대 메시지 크기 - 애플리케이션이 전송/수신할 메시지의 최대 크기.

■ UL 최대 크기

■ DL 최대 크기

○ 주기 - 이것은 애플리케이션이 얼마나 자주 ADDS를 이용하여 데이터 전송을 수행하려고 하는지를 나타낸다. 이것은 애플리케이션 절차 또는 세션에 관련될 수 있다.

○ 데이터 전송 지속기간 - ADDS를 통해 데이터 전송이 이용될 지속기간

○ 메시지 레이트 - '데이터 전송의 지속기간'에서 전송/수신될 메시지의 개수. 이것은 2개의 서브필드를 가질 수 있다.

■ UL 메시지 레이트

■ DL 메시지 레이트

○ 데이터의 최대 총량 - 전송될 데이터의 최대 총량. 이것은 2개의 서브필드를 가질 수 있다.

■ UL 최대 데이터

■ DL 최대 데이터

○ 메시지 폐기 - 통신이 협의된 파라미터들을 초과하는지를 나타내는 플래그. 예를 들어, 메시지 크기 또는 레이트가 더 높을 경우.

○ 수락가능한 메시지 손실률

○ 신뢰가능한 전달

■ 메시지 제출 보고

■ 메시지 전달 보고

이들 파라미터들 모두는 강제사항은 아니다. 이것은 애플리케이션 데이터 전송 요구조건을 기술하는 애플리케이션 필요성에 따라 포함될 수 있다. 예를 들어, 온도 판독 애플리케이션이 시간 단위로 판독치를 전송해야 한다면, 다음과 같은 특성을 설정할 수 있다

● 지연 용인: 25분

● 주기 : 매 1시간

● 전송의 지속기간: 5초

● 최대 메시지 크기

○ UL 최대 크기 : 120 바이트

○ DL 최대 크기 : 80 바이트

● 메시지 레이트

○ UL 메시지 레이트 : 4

○ DL 메시지 레이트 : 2

● 최대 총 데이터

○ UL 최대 데이터 : 350 바이트

○ DL 최대 데이터 : 100 바이트

g. 디바이스 정보

이것은 선택사항적 필드이다. 디바이스 레벨 정보는 또한, ADDS 메시지 스케줄링 및 라우팅에서 ADDS 엔티티를 보조하기 위해 제공될 수 있다.

- 디바이스 가용 시간 - 디바이스가 MT 데이터에 대해 연락될 수 있는 때.

- 디바이스 이동성 정보 - 디바이스가 정지되어 있을 수 있는지 또는 로밍중일 수 있는지.

h. ADDS 옵션

i. 메시지 통보 요청됨

이 옵션이 설정되면, ADDS 엔티티는 메시지를 저장하고 ADDS 메시지 및 메시지 상세사항(크기 등)의 도착을 엔드 노드에게 통보할 수 있다. ADDS 클라이언트는 나중에 메시지를 가져올 수 있다.

ii. 통보를 위한 최대 메시지 크기

통보가 전송되어야 하는 최대 메시지 크기.

i. 가용 트랜스포트 경로

디바이스에서 이용가능한 상이한 트랜스포트 메커니즘/경로들의 목록 및 그들의 특성. 다음과 같은 정보 중 하나 이상이 제공될 수 있다. 정보는 디바이스 타입에 따라 다르다(예를 들어, NAS는 UE에만 적용가능):

1. SMS

a. SMS-SC 주소

b. 디바이스의 MSISDN

c. 최대 메시지 크기

d. 이용될 데이터-코딩

e. 이용될 SMS 애플리케이션 포트 번호

2. NAS

a. 최대 메시지 크기

3. USSD

a. USSD 코드

4. 사용자 평면

a. 이용될 IP 주소

b. 이용될 트랜스포트 프로토콜

단계 4에서, ADDS 엔티티(322)는 'ADDS 가입 요청' 메시지를 HSS(116)에 전송한다. 이 메시지는 다음과 같은 정보를 포함할 수 있다.

a. 디바이스 타입

b. 디바이스 식별자

c. 디바이스 상세사항

d. 보고된 트랜스포트 경로

e. 요청된 애플리케이션 식별자

제공된 '디바이스 식별자'는 대응하는 가입 레코드를 회수하기 위하여 IMSI 또는 'SCS-Identity'로 변환되어야 할 것이다. HSS/UDR은 '디바이스 식별자' 변환 절차를 실행할 수 있고, DNS 서버, MME, SGSN, PGW 등과 같은 일부 노드에 연락하여 디바이스 식별자를 IMSI 또는 'SCS-Identity'로 변환할 수 있다. '외부 식별자' 또는 'MSISDN' 등의 ID들 중 일부는 HSS/UDR 자체에 의해 변환될 수 있다. HSS/UDR은 관련된 가입 정보를 회수하고 UE 또는 SCS가 ADDS 서비스를 이용하는 것이 인가되어 있는지 체크한다.

단계 5에서, HSS/UDR은 다음과 같은 ADDS 인가 정보를 포함하는 ADDS 가입 응답 메시지를 전송한다 :

a. IMSI 또는 SCS 식별자

b. 가입 정보

i. 허용된 트랜스포트 경로

ii. 가입된 애플리케이션 ID

iii. 애플리케이션 ID 이식성 - 애플리케이션이 호스트 디바이스들을 변경할 수 있도록 애플리케이션 ID가 할당되어야 하는지를 나타낸다.

iv. 디바이스 특성 - 가입된/제한된 디바이스

디바이스 이동성 상세사항 및 가용성 시간 등의 특성(예를 들어, MTC 피쳐)

v. 피어 정보 - 대응하는 SCS 및 SCS에 보고될 이벤트 등

단계 6에서, ADDS 엔티티는 ADDS 특정 정책 및 과금 정보를 요청하기 위해 'ADDS 정책 요청' 메시지를 PCRF에 전송한다. 이 메시지는 다음과 같은 정보를 포함할 수 있다:

a. IMSI 또는 SCS-식별자

b. 애플리케이션 상세사항/특성

단계 7에서, PCRF(334)는 애플리케이션에 이용될 정책 및 과금 상세사항을 제공하는 'ADDS 정책 응답' 메시지로 응답한다. 이 메시지는 다음과 같은 정보를 포함할 수 있다:

a. 정책 정보 - 메시지 스케쥴링, 크기 및 라우팅 정보

b. 과금 정보

단계 8에서, ADDS 엔티티(322)는 자신의 디바이스들 중 하나가 ADDS에 대한 애플리케이션을 등록했다는 것을 SCS 등의 엔드 노드에게 통보하기 위해 'ADDS 애플리케이션 이벤트 통보' 메시지를 전송한다. 관심있는 애플리케이션은 이하에서 설명되는 'ADDS 이벤트 가입 절차'에 따라 이 이벤트에 대해 등록할 수 있다. 다음과 같은 상세사항이 이 메시지에서 전송될 수 있다:

a. 목적지 애플리케이션 ID - 통보를 수신해야 하는 목적지 애플리케이션

b. 발생 이벤트 타입 : 이것은 '애플리케이션 등록 이벤트'로 설정될 수 있다.

c. 애플리케이션 ID - 등록 애플리케이션에 할당된 애플리케이션 ID

d. 디바이스 정보

e. 단계 3f에서 설명된 애플리케이션 상세사항

단계 9에서, 엔드 노드는 'ADDS 애플리케이션 이벤트 응답' 메시지를 전송한다. SCS는 일부 인가 정보 및 애플리케이션에 전달될 필요가 있는 정보로 응답할 수 있다. 이 메시지는 다음과 같은 정보를 포함할 수 있다:

a. 정책 정보 - 적용될 애플리케이션 특성.

b. 과금 정보 - 적용될 오프라인 온라인 과금 등 및 애플리케이션이 SCS에 의해 후원되는 경우.

c. 애플리케이션 제약 - UE 애플리케이션이 다른 애플리케이션과 통신하는 것이 허용될 수 있는지 또는 그 통신이 SCS로만 제약되어야 하는지 등의 정보. ADDS 엔티티는, 다른 어떠한 엔드 노드도 UE의 애플리케이션에 메시지를 전송하고 있지 않으며 및/또는 UE도 역시 다른 엔드 노드에도 전송하고 있지 않다는 것을 보장할 수 있다.

d. 피어 애플리케이션 정보 - UE에 제공될 대응하는 SCS 애플리케이션 ID 및 그 특성 등.

단계 10에서, ADDS 엔티티는 'ADDS 애플리케이션 등록 수락' 메시지를 엔드 노드의 ADDS 클라이언트에 전송한다. 이 메시지는 다음과 같은 정보를 포함한다:

a. 할당된 애플리케이션 식별자

b. 애플리케이션 ID 이식성

c. 애플리케이션 ID 임대 시간

d. 허용된 트랜스포트 경로들 및 그들의 특성. 이것은 표 6 2에 열거된 정보와 유사하다

e. 협상된 애플리케이션 특성 - 이것은 네트워크가 수락한 최종 애플리케이션 특성일 것이다.

f. 보안 토큰

g. 피어 애플리케이션 정보

마지막으로, 단계 11에서, ADDS 클라이언트는 ADDS 엔티티로부터 수신된 정보를 애플리케이션에 전달한다. 이 정보는 다음과 같은 것들을 포함할 수 있다

a. 할당된 애플리케이션 식별자

b. 애플리케이션 ID 이식성

c. 애플리케이션 ID 임대 시간

d. 협상된 애플리케이션 특성

e. 보안 토큰

f. 피어 애플리케이션 정보

ADDS 업데이트 절차

ADDS 클라이언트(324) 또는 네트워크 ADDS 엔티티(322)는 ADDS 능력 또는 애플리케이션 특성에서의 임의의 변화에 대해 통보하기 위해 ADDS 업데이트 절차를 수행할 수 있다. 이 절차는, (엔드 노드의 모든 애플리케이션에 영향을 미치는) 경로 레벨 변경에 대해 또는 (애플리케이션 특성과 같은) 애플리케이션 레벨 변경마다 ADDS에 통보하는 데 이용될 수 있다. 이 절차를 이용하여 다음과 같은 특성 및 능력들이 업데이트될 수 있다.

1. 데이터 경로 변경

2. 애플리케이션 특성 변경

3. UE 특성 변경

4. ADDS 옵션 변경

5. 가입 변경

6. 애플리케이션 ID 갱신

이 절차는 엔드 노드 또는 네트워크 ADDS 엔티티에 의해 개시될 수 있으며, 절차는 어느 엔티티가 절차를 시작하는지에 따라 다소 상이하다. 양쪽 변형이 도 14에 도시되어 있다.

엔드 노드 개시형 ADDS 업데이트 절차

엔드 노드의 ADDS 클라이언트는 다음과 같은 이벤트들에 기초하여 ADDS 업데이트 메시지를 전송하기로 결정할 수 있다 :

a. 애플리케이션 표시. 애플리케이션이 ADDS 클라이언트에 대한 통신 요건/특성을 업데이트한다.

b. 사용자 제공 엔드 노드의 사용자가, 이용가능한 전송 경로들 또는 그들의 특성과 같은 노드의 ADDS 능력에 영향을 주는 일부 노드 레벨 파라미터를 변경했다.

c. 애플리케이션 ID 갱신- 애플리케이션 ID 대여 타이머가 이제 곧 만료하며 갱신될 필요가 있다.

도 14의 단계들 A1 내지 A6은 엔드 노드가 ADDS 업데이트 절차를 개시하고 수행하는 프로세스의 한 실시예를 나타낸다. 도시된 바와 같이, 단계 A1에서, ADDS 클라이언트는 다음과 같은 정보를 포함할 수 있는 'ADDS 업데이트 요청' 메시지를 ADDS 엔티티에 전송한다 :

a. ADDS 메시지 타입 - 이것이 'ADDS 업데이트 요청' 메시지임을 나타낸다

b. 업데이트 타입 - 이것은 애플리케이션 레벨 또는 엔드 노드 레벨일 수 있다. 이것은 다음과 같은 값들 중 임의의 것을 취할 수 있다.

i. 애플리케이션 특성 업데이트

ii. 애플리케이션 ID 갱신

iii. 디바이스 특성 업데이트

iv. 가용 트랜스포트 경로

v. ADDS 옵션 업데이트

유의사항: 다음과 같은 IE들의 포함은 업데이트 타입에 의존한다. 이들 IE들은 6.7.1의 단계 3에서 상세하게 설명된다.

c. 애플리케이션 ID - 이것은 특정한 애플리케이션 상세사항이 업데이트되어할 경우 포함된다.

d. 애플리케이션 상세사항

e. 디바이스 정보

f. ADDS 옵션

g. 디바이스 신원 - 디바이스는 'ADDS 애플리케이션 등록 절차'에서 제공되는 것과 동일한 신원을 제공해야 한다

단계 A2에서, ADDS 엔티티는 업데이트된 특성에 기초하여 업데이트된 정책 정보를 얻기 위해 'ADDS 정책 업데이트 요청 메시지를 PCRF에 전송한다.

단계 A3에서, PCRF는 업데이트된 정책 및 과금 정보와 함께 'ADDS 정책 업데이트 응답' 메시지를 전송한다.

단계 A4에서, ADDS 엔티티는 'ADDS 애플리케이션 이벤트 통보' 메시지를 피어 어플리케이션 엔드 노드에 전송한다. 이 메시지는, 피어 어플리케이션 엔드 노드 정보가 가입 정보에서 이용가능하거나 노드가 이하에서 설명되는 'ADDS 이벤트 가입 절차'를 이용하여 통보에 대해 가입한 경우에 전송될 수 있다. 이 단계는 도 13의 단계 8과 유사하다.

단계 A5에서, 엔드 노드는 'ADDS 애플리케이션 이벤트 응답' 메시지를 전송한다. 이 단계는 도 13의 단계 9와 유사하다.

단계 A6에서, ADDS 엔티티는 네트워크에 의해 수락되는 파라미터를 제공하기 위해 'ADDS 업데이트 응답' 메시지를 전송한다. 이 메시지는 도 13의 단계 10에서 설명된 'ADDS 등록 수락' 메시지와 유사한 정보를 포함한다.

네트워크 개시형 ADDS 업데이트 절차

네트워크의 ADDS 엔티티는, ADDS 클라이언트에 ADDS 업데이트 명령 메시지를 전송하여 소정 변경에 대해 통보하거나 이용되어야 할 트랜스포트 경로에 관한 명령을 제공하기로 결정할 수 있다. 이 메시지는 다음과 같은 이벤트들에 기초하여 전송될 수 있다:

a. 오퍼레이터 제공

b. 과부하 상태 또는 다른 노드/서비스 가용성 등의 네트워크 상태

c. PCRF로부터의 정책 변경 통보

d. HSS/UDR로부터의 가입 변경 통보

도 14의 단계 B1 내지 B4는 네트워크 ADDS 엔티티가 ADDS 업데이트 절차를 개시하고 수행하는 프로세스의 한 실시예를 나타낸다.

도시된 바와 같이, 단계 B1에서, ADDS 엔티티는 'ADDS 업데이트 명령' 메시지를 엔드 노드의 ADDS 클라이언트에 전송한다. 이 업데이트는 특정 애플리케이션 또는 엔드 노드에 대한 것일 수 있다. 이 메시지는 다음과 같은 정보를 포함할 수 있다

a. ADDS 메시지 타입 - 이것이 'ADDS 업데이트 명령 요청' 메시지임을 나타낸다

b. 업데이트 타입 - 특정 애플리케이션이 영향을 받거나 엔드 노드가 영향을 받는지를 나타낸다.

유의사항: 다음과 같은 IE들의 포함은 업데이트 타입에 의존한다. 이들 IE들은 도 13과 관련하여 위에서 상세하게 설명된다.

c. 애플리케이션 ID - 이것은 특정한 애플리케이션 상세사항이 업데이트되어할 경우 포함된다.

d. 애플리케이션 ID 임대 시간

e. 협상된 애플리케이션 특성

f. ADDS 엔티티 트랜스포트 경로 정보

ADDS 클라이언트는 정보를 수신하고 그에 따라 자신을 구성한다. 이것은 업데이트되는 정보에 기초하여 영향받는 애플리케이션에게 선택사항으로서 통보할 수 있다.

단계 B2는 상기 단계 A4와 유사하고, 단계 B3은 상기 단계 A5와 유사하다.

단계 B4에서, ADDS 클라이언트는, ADDS 클라이언트가 제공된 정보로 자신을 업데이트했음을 확인해 주기 위해 ADDS 엔티티에 'ADDS 업데이트 명령 응답'을 전송한다.

ADDS 데이터 전송

ADDS 데이터 전송 절차는 ADDS를 이용하여 데이터를 전송하기 위해 애플리케이션에 의해 이용되는 절차이다. 이 절차는 ADDS 엔드 노드(SCS/UE)에 존재하는 애플리케이션이 ADDS를 이용하여 애플리케이션 특유의 데이터를 전송할 수 있게 한다. ADDS 엔드 노드는 애플리케이션 식별자를 목적지 식별자로서 이용하고 애플리케이션 데이터와 그 특성을 기저 ADDS 클라이언트에 전달한다. ADDS 클라이언트는 메시지를 ADDS 서버에 트랜스포트하기 위해 전달 메커니즘/경로를 선택한다. ADDS 클라이언트는 또한, (예를 들어, NAS 및 SMS의 경우에) 애플리케이션 데이터의 크기가 선택된 트랜스포트 프로토콜에서 지원되는 페이로드의 최대 한계를 초과한다면 애플리케이션 데이터에 대한 세그먼트화를 수행할 수 있다. ADDS 엔티티는, 데이터를 목적지 애플리케이션에 전달하는 시간과 방법을 결정하는 데 있어서 네트워크 정책, 부하 상태, 엔드 노드 상태 및 애플리케이션 데이터 특성을 고려한다. ADDS 엔티티는 과금 제어를 목적으로 OFCS 및 OCS와 상호작용할 수 있다.

전송 애플리케이션은 신뢰성있는 데이터 전달을 요청할 수 있고, ADDS에게 데이터 수신의 접수확인을 요청할 수 있으며, 또한 ADDS 메시지가 언제 예정된 애플리케이션에 성공적으로 전달되었는지에 관한 전달 보고를 제공할 수 있다.

데이터 전달 통보 절차

한 실시예에서, 수신 애플리케이션/엔드 노드가 (애플리케이션 등록 절차와 관련하여 전술된 바와 같이) ADDS 메시지를 전달하기 전에 ADDS 메시지에 관해 통보받을 것을 ADDS에게 요청했다면, ADDS 엔티티는 메시지에 관한 상세사항을 포함하는 통보를 엔드 노드에 전송한다. 그러면, 엔드 노드/애플리케이션은 나중에 이 메시지를 회수하기 위해 특정한 요청을 전송할 수 있다. 선택사항으로서, 엔드 노드는 메시지가 즉시 전달되어야 하거나 전달 시도가 이루어질 수 있는 기간을 제공해야 한다면 통보 확인 메시지에서 플래그를 설정할 수 있다.

데이터 질의/폴링 절차

한 실시예에서, ADDS 클라이언트 또는 애플리케이션은 ADDS 엔티티에 질의를 전송하여 임의의 데이터가 전달 보류중인지를 검사하고 메시지 상세사항을 요청하거나 전달될 실제 메시지를 요청할 수 있다.

등록없는 데이터 전송

한 실시예에서, 애플리케이션이 소스 애플리케이션을 등록하지 않고 데이터 전송 요청을 전송하는 것이 가능하다. 이러한 경우, ADDS는 메시지 전달을 시도하기 전에 HSS(116)/UDR 및 PCRF(334)로 인가를 체크할 수 있다.

수신 애플리케이션도 역시 등록되지 않는 것이 가능할 수 있다. 예를 들어, 예약된 애플리케이션 식별자가 이용되는 경우이다. 여기서, 데이터 전송 요청 메시지는, 메시지가 올바른 엔드 노드에 전달되고 예약된 애플리케이션 식별자에 대해 마킹된 엔드 노드의 애플리케이션이 메시지를 수신할 수 있도록, 추가적으로 디바이스 식별자를 가질 수 있다.

그러나, 이들 양쪽 경우 모두에서, 전송 및 수신 엔드 노드는 자신의 ADDS 능력을 네트워크에게 표시했어야 한다.

도 15는, 데이터 메시지 통보, 질의 및 절차의 요청 부분을 포함하는, 한 실시예에 따른 ADDS 데이터 전달 프로세스를 나타내는 흐름도이다.

도시된 바와 같이, 단계 1에서, UE 또는 SCS(340) 내의 ADDS 클라이언트는 ADDS 데이터 전송 요청을 ADDS 엔티티(322)에 전송한다. 전술된 바와 같이, ADDS 클라이언트는 상기 경로 선택 섹션에서 설명된 방식으로 트랜스포트 메커니즘/경로를 선택한다. 예를 들어, ADDS 클라이언트는, 메시지의 크기, 트랜스포트 경로의 상태 및 디바이스 상태(유휴 모드에 있는 경우 등)를 포함한 다양한 기준에 따라 트랜스포트 메커니즘/경로를 선택할 수 있다. 한 실시예에서, 다음과 같은 정보가 이 메시지에서 전송된다 :

a. ADDS 메시지 타입 :

이것은 메시지가 'ADDS 데이터 전송 요청' 메시지임을 나타낸다.

b. 소스 애플리케이션 식별자:

애플리케이션 등록 절차 동안에 애플리케이션이 가져온 애플리케이션 식별자 또는 예약된 애플리케이션 식별자

c. 목적지 애플리케이션 식별자:

애플리케이션이 데이터를 전송하고자 하는 목적지의 애플리케이션 식별자.

d. 목적지 디바이스 식별자:

이것은 선택사항적 필드이며 '목적지 애플리케이션 식별자'가 예약된 애플리케이션 식별자인 경우 포함된다. 이 필드는 도 13의 단계 3에서 설명된다.

e. 애플리케이션 데이터:

엔드 애플리케이션에 전달될 필요가 있는 실제 데이터를 포함하는 애플리케이션 특유의 데이터.

f. 애플리케이션 데이터 특성:

데이터의 특성 및 전달 명령은 이 IE에서 제공된다. 메시지 중요도는 다음으로서 제공될 수 있다:

i. 중요한

ii. 보통

iii. 없어도 되는

추가적으로 엔드 애플리케이션으로의 전달 또는 통보의 시간도 역시 제공될 수 있다. 메시지가 유효 기간 내에 전달될 수 없다면 ADDS 엔티티로부터 삭제되도록 메시지 유효성 필드가 제공될 수도 있다.

g. 제출 상태 통보

이 플래그는, ADDS 엔티티가 ADDS 메시지의 성공적인 수신에 관한 접수확인을 소스 애플리케이션에게 전송해야 하는지를 나타낸다.

h. 전달 상태 통보

메시지가 목적지 애플리케이션에 성공적으로 전달된 후에 소스 애플리케이션이 전달 보고를 받기를 원하는지를 ADDS 엔티티에게 표시한다.

단계 2에서, ADDS 엔티티는 전송 애플리케이션 및/또는 수신 애플리케이션이 이전에 등록되지 않았다면 인가 정보에 대해 HSS(116)/UDR 및 PCRF(334)로 체크할 수 있다. 이 절차는 도 13에서 설명된 방법으로 수행된 체크와 유사하다. 이 절차는 또한, '목적지 디바이스 식별자'를 IMSI/SCS ID 등의 로컬 식별자로 변환하는 데 이용될 수 있다.

단계 3에서, 온라인 과금이 이용되면, ADDS 엔티티는 ADDS 데이터 전송 절차의 인가를 위해 3GPP TS 32.296에 기술된 신용 제어 절차를 수행할 수 있다.

단계 4에서, ADDS 서버는 메시지가 전달에 대해 수락되었음을 접수확인하는 ADDS 데이터 전송 수락 메시지를 전송한다. 이것은 선택사항적 메시지이며, 'ADDS 데이터 전송 요청' 메시지에서 '제출 상태 통보' 플래그가 설정된 경우에만 전송된다. 이 메시지는, 서버가 목적지 애플리케이션 식별자를 유효하지 않거나 충분한 신용이 이용가능하지 않다고 식별한 경우 에러 코드를 포함할 수 있다. 에러 코드는 또한, 요청 기능(애플리케이션 데이터 특성 필드에서 요청됨)이 지원되지 않았는지를 통보할 수도 있다. ADDS 엔티티는 애플리케이션 특성 및 네트워크 상태에 따라 메시지를 저장하거나 통보를 전송하거나 메시지 전달을 시도할 수 있다.

단계 5에서, ADDS 엔티티는, 수신 엔드 노드가 통보를 요청한 경우, 수신 엔드 노드에 'ADDS 데이터 통보' 메시지를 전송한다. 본 실시예에서, 이 메시지는 다음과 같은 정보를 포함한다:

a. 메시지 크기

b. 메시지 식별 번호(이것은 메시지의 시퀀스 번호 또는 ADDS에 의해 할당되는 임시 식별자일 수 있음)

c. 전송 애플리케이션 식별자

d. 수신 애플리케이션 식별자

e. 메시지 중요도

f. 메시지 유효성

단계 6에서, 엔드 노드는 자신이 메시지에 주목했다는 것을 나타내는 'ADDS 데이터 통보 Ack' 메시지를 전송한다. 또한, 이 메시지는 선택사항적으로, 표시된 메시지가 즉시 전달되어야 한다는 플래그 및 메시지가 그 시간에 전달되어야 한다는 것을 나타내기 위한 또 다른 선택사항적 기간 값을 포함할 수 있다. 즉각적인 전달이 요청된다면, 이 시점에서 10 이후로부터의 단계들이 수행된다.

그렇지 않다면, 단계 7에서, ADDS 클라이언트는, 보류중인 메시지들 또는 보류중인 메시지들의 전달에 관한 정보를 요청하기 위해 ADDS 엔티티에게 'ADDS 데이터 질의' 메시지를 전송할 수 있다.

단계 8에서, ADDS 엔티티는 보류중인 메시지에 관한 정보를 제공하는 'ADDS 데이터 질의' Ack 메시지를 전송한다. 이 메시지는 보류중인 메시지들 각각에 대해 단계 5에 열거된 정보를 포함할 수 있다. 실제 메시지 전달이 요청되었다면, 단계 10 이후의 단계들이 수행된다.

단계 9에서, 엔드 노드는 ADDS 엔티티에 '데이터 요청' 메시지를 전송하고 (단계 5에서와 같이) 이전에 통보되었거나 단계 7에서 ADDS 질의 메시지에서 학습된 특정 메시지의 전달을 요청할 수 있다. 이 메시지는 요청되고 있는 메시지를 식별하는 '메시지 식별 번호'를 포함할 수 있다. 단계 10 이후의 단계들은 이 메시지의 수신 이후에 수행된다.

단계 10에서, ADDS 엔티티는 애플리케이션 데이터를 전달하기 위해 'ADDS 데이터 전달' 메시지를 전송한다. ADDS 엔티티는 데이터 전달을 위한 트랜스포트 경로를 선택할 수 있다. ADDS 엔티티는 목적지 애플리케이션 식별자를 이용하여, 맵핑 테이블로부터, SMS용 MSISDN, NAS용 IMSI 및 사용자 평면용 IP 주소와 같은 선택된 경로에 대한 정보를 어드레싱하는 엔드 노드를 찾는다. ADDS 엔티티(322)는 선택된 경로에 대한 (IP 헤더 등의) 메시지를 구축하고 그 메시지를 전송할 수 있다. 이 메시지에는 다음과 같은 정보가 존재할 수 있다. 이 정보 중 일부는 상기 1 단계에서 설명된다:

a. ADDS 메시지 타입 :

이것은 메시지가 'ADDS 데이터 전달 요청' 메시지임을 나타낸다.

b. 소스 애플리케이션 식별자:

c. 목적지 애플리케이션 식별자:

d. 애플리케이션 데이터:

e. 애플리케이션 데이터 특성:

'메시지 중요성' 등의, 단계 1에 열거된 정보 중 일부가 제공될 수 있다.

f. 전달 상태 표시

이 플래그는 수신 노드가 ADDS 메시지의 성공적인 수신을 접수확인해야 하는지를 나타낸다.

단계 11에서, 엔드 노드는 메시지가 성공적으로 엔드 애플리케이션에 처리/전달되었음을 나타내는 'ADDS 데이터 전달 Ack' 메시지를 전송한다. 이 메시지는, 메시지 처리시에 임의의 디코딩 실패와 같은 에러가 엔드 애플리케이션('목적지 애플리케이션 식별자'로 표시됨)가 이용가능하지 않다면, 에러 코드를 포함할 수 있다.

이 메시지는 또한 응답 데이터 패킷을 소스 애플리케이션에 운반하도록 강화될 수 있다. 이 경우에, 이 메시지는 단계 1에 열거된 정보를 포함할 수 있다. 소스 애플리케이션 ID, 목적지 애플리케이션 ID와 같은 정보 중 일부는 생략될 수 있으며, 이 정보는 ADDS 엔티티에 의해 채워질 수 있다. 이 목적을 위해 ADDS 엔티티는 'ADDS 데이터 전달 Ack'메시지를 수신할 때까지 실제 메시지를 보유할 수 있다. 이 메시지에서 데이터가 전송된다면, 이것은 'ADDS 데이터 전송 요청' 메시지와 유사한 것으로 간주될 수 있으며 단계 1로부터의 단계들이 후속될 수 있다.

단계 12에서, ADDS 엔티티는, 'ADDS 데이터 전송 완료' 메시지를 발신 애플리케이션에 전송함으로써 메시지의 성공적인 전달을 나타내기 위해 소스 애플리케이션에 전달 보고를 제공한다. 이 메시지는 메시지 전달의 타임 스탬프를 포함할 수 있다.

마지막으로, ADDS 엔티티는 ADDS 메시지 전달의 과금 목적을 위해 OFCS(332)에 과금 상세사항을 제공할 수 있다.

ADDS 이벤트 가입

도 16은 본 발명의 한 실시예에 따른 ADDS 이벤트 가입을 위한 방법을 나타낸다. 애플리케이션은 ADDS(322)에 이벤트 가입을 전송할 수 있고, 예를 들어, 등록 취소 등의, 이들 애플리케이션에서 발생하는 이벤트들을 통보받아야하는 애플리케이션 식별자들의 목록을 제공할 수 있다. ADDS 엔티티(322)는 이 정보를 그 메모리에 저장하고 이벤트에 관한 통보를 요청된 애플리케이션에 전송한다.

도 16을 참조하면, 단계 1에서, 엔드 노드(예컨대, UE(214) 또는 SCS(340))는 'ADDS 이벤트 가입 요청' 메시지를 ADDS 엔티티에 전송한다. 이 메시지는 다음과 같은 정보를 포함할 수 있다

a. 소스 애플리케이션 ID: 통보를 받을 필요가 있는 애플리케이션.

b. 소스 디바이스 ID: 이 필드는 선택사항이며, 소스 애플리케이션이 ADDS에 등록되어 있지 않거나 예약 된 애플리케이션 ID가 이용되는 경우 포함된다.

c. 이벤트 가입 목록

i. 타겟 애플리케이션 ID

ii. 타겟 디바이스 ID: 이것은 타겟 애플리케이션 ID를 알 수 없는 경우 포함될 수 있다. 예를 들어, SCS가 UE로부터 애플리케이션 등록 이벤트에 대해 알기를 원하면, SCS는 UE의 외부 식별자를 제공하여 (도 13의 설명과 관련하여 전술된 바와 같이) UE가 애플리케이션을 등록할 때 SCS가 통보받도록 할 수 있다

iii. 가입된 이벤트들: 통보가 요구되는 이벤트들의 목록. 한 실시예에서, 이벤트들은 다음과 같은 것일 수 있다:

1. 애플리케이션 등록

2. 애플리케이션 등록취소

3. 애플리케이션 이동(예를 들어, 호스트 디바이스를 변경하는 애플리케이션)

단계 2에서, ADDS 엔티티는 수락된 이벤트들의 목록을 제공하기 위해 'ADDS 이벤트 가입 Ack' 메시지를 전송한다.

애플리케이션 등록취소

도 17은 애플리케이션 등록취소를 위한 방법을 나타낸다. 등록취소는 엔드 노드(도 17의 단계 A1 내지 A4) 또는 네트워크(도 17의 단계 B1 내지 B4)에 의해 개시될 수 있다. 애플리케이션 등록취소 절차는, 엔드 노드가 그들의 ADDS 이용을 정상적으로 종료할 수 있게 한다. 애플리케이션이 등록취소될 때, ADDS 엔티티(322)는 할당된 애플리케이션 ID를 해제하고 그와 연관된 트랜스포트 맵핑을 제거한다. ADDS 엔티티는 또한, 다른 관심있는 애플리케이션들에 등록취소에 관해 통보할 수 있다.

한 실시예에서, ADDS 클라이언트는 (애플리케이션 ID와 디바이스 정보의 맵핑 상세사항과 같은) 임의의 애플리케이션 특유의 데이터를 제거하고 애플리케이션에게 절차의 종료를 통보할 수 있다.

한 실시예에서, 네트워크는 다음과 같은 이유들 중 임의의 이유로 이 절차를 시작할 수 있다:

1. ADDS 가입 철회

2. 애플리케이션 ID 임대 시간 만료

3. PCRF로부터 표시된 정책에 기초하여

4. 신용의 이용불능에 관한 OCS로부터의 표시

또한 한 실시예에서, 이 절차는 다음과 같은 이유들 중 임의의 이유로 엔드 노드에 의해 시작될 수 있다:

1. 애플리케이션 셧다운

2. ADDS 클라이언트 셧다운

3. 애플리케이션으로부터의 표시

일부 시나리오들에서, 애플리케이션은 사용자 평면 경로를 통해 정규 데이터 통신을 계속할 수 있는 동안 ADDS 통신을 종료하기를 원할 수도 있다는 점에 유의한다.

애플리케이션이 등록취소될 때, 관심있는 애플리케이션들 또는 엔드 노드들은 이에 관해 통보받을 수 있다. 통보받을 애플리케이션 또는 엔드 노드들은 다음에 기준하여 결정될 수 있다:

1. 등록취소되는 애플리케이션에 의해 제공된 목록.

2. 도 16과 관련하여 앞서 언급된 다른 애플리케이션들로부터의 이벤트 가입.

3. HSS/UDR로부터의 가입 정보

엔드 노드 개시형 등록취소

도 17의 단계 A1 내지 A4는 엔드 노드 개시형 등록취소를 나타낸다. 도시된 바와 같이, 단계 A1에서, ADDS 엔드 노드는 ADDS 엔티티(322)에 'ADDS 애플리케이션 등록취소 요청' 메시지를 전송한다. 이 메시지는 다음과 같은 정보를 포함할 수 있다:

a. 메시지 타입 :

이것은 'ADDS 애플리케이션 등록취소 요청'으로 설정될 것이다.

b. 등록취소 사유 :

ADDS 클라이언트 셧다운 또는 애플리케이션 셧다운 등과 같은 등록취소의 사유.

c. 등록취소 응답 플래그 :

이 플래그는 ADDS 엔드 노드가 등록취소 응답을 기대하는지를 나타낸다. 일부 소형/제약된 디바이스는 이 플래그를 FALSE로 설정하여 ADDS 엔티티가 응답을 보내지 말것을 나타낼 수 있다. 이 플래그는 또한, ADDS 클라이언트가 셧다운될 때 FALSE로 설정될 수 있다.

d. 애플리케이션 식별자:

등록취소될 필요가 있는 애플리케이션 식별자.

e. 통보 목록:

등록취소에 대해 통보될 필요가 있는 다른 애플리케이션 식별자들의 목록. ADDS 클라이언트가 셧다운되면 각각의 애플리케이션 ID에 대한 '애플리케이션 식별자'의 목록 및 '통보 목록'이 제공될 수 있다.

단계 A2에서, ADDS 엔티티(322)는 'ADDS 애플리케이션 이벤트 통보' 메시지를 통보받을 애플리케이션/엔드 노드에 전송한다. 이 메시지는 다음과 같은 정보를 포함할 수 있다:

a. 목적지 애플리케이션 ID:

이 통보를 수신해야 하는 목적지 애플리케이션

b. 발생된 이벤트 타입:

이것은 '애플리케이션 등록취소'로 설정될 것이다.

c. 등록취소 사유 :

d. 영향받는 애플리케이션 ID:

등록취소될 애플리케이션 ID.

e. 디바이스 정보:

이것은 애플리케이션이 존재하는 엔드 노드에 관한 정보를 포함할 수 있다.

단계 A3에서, 엔드 노드는 자신이 이벤트 통보 메시지를 수신했다는 것을 확인시켜주기 위해 'ADDS 애플리케이션 이벤트 통보 Ack' 메시지를 ADDS 엔티티(322)에 전송한다.

마지막으로, 단계 A4에서, ADDS 엔티티는 등록취소 절차가 완료되었다는 것을 통보하기 위해 'ADDS 등록취소 수락' 메시지를 엔드 노드에 전송한다.

네트워크 개시형 등록취소

도 17의 단계 B1 내지 B4는 네트워크 개시형 등록취소를 나타낸다. 도시된 바와 같이, 단계 B1에서, ADDS 엔티티(322)는 'ADDS 애플리케이션 등록취소 명령' 메시지를 엔드 노드에 전송하며, 이 메시지는 다음과 같은 정보를 포함할 수 있다 :

a. 영향받는 애플리케이션 ID:

등록취소될 애플리케이션 ID. 하나보다 많은 애플리케이션이 등록취소되는 경우 이들 ID들의 목록이 제공될 수 있다.

b. 등록취소 사유 :

단계 B2에서, ADDS 엔티티는 'ADDS 애플리케이션 이벤트 통보'를 통보받을 애플리케이션/엔드 노드에 전송할 수 있다. 이 메시지는 상기 단계 A2에서 설명된다. B1 단계에서 이 메시지와 'ADDS 애플리케이션 등록취소 명령'이 동시에 전송될 수 있으며 순서는 중요하지 않다.

단계 B3에서, 엔드 노드는 자신이 이벤트 통보 메시지를 수신했다는 것을 확인시켜주기 위해 'ADDS 애플리케이션 이벤트 통보 Ack' 메시지를 ADDS 엔티티에 전송한다.

단계 B4에서, ADDS 클라이언트는 등록취소 절차가 완료되었다는 것을 통보하기 위해 'ADDS 등록취소 명령 수락' 메시지를 엔드 노드에 전송한다.

다른 피쳐들

EPC에서 ADDS의 도입과 ADDS의 피쳐들은 M2M 타입 통신에 유익할 수 있다. ADDS는 M2M 통신을 위한 전문화된 기능/서비스를 제공하도록 강화될 수 있다.

한 예로서, ADDS는 저장소로서 동작하여 M2M 디바이스 및 M2M 게이트웨이에 관련된 일부 정보를 유지할 수 있다. SCS가 ADDS 메시지를 이용하여 이러한 정보를 질의할 때, ADDS는 메시지를 조사하여 질의받고 있는 자원 명칭을 찾고 이 질의를 엔드 M2M 게이트웨이 나 최종 M2M 디바이스 애플리케이션에 포워딩하지 않고도 자율적으로 이 정보를 제공할 수 있다.

이러한 방식으로 ADDS는 일부 M2M 애플리케이션에 대한 프록시로서 동작할 수 있고 특정 질의에 응답할 수 있다. 따라서 디바이스들이 오프라인 일 때 일부 데이터를 여전히 가져올 수 있다.

이 접근법은 무선으로 전송되는 메시지의 수를 절감하고, 무선 자원, 네트워크 자원 및 디바이스 배터리 전력을 절약할 수 있다. 예를 들어 동일한 자원 정보가 복수의 네트워크측 애플리케이션에 의해 질의된다면, ADDS는 이 정보를 한 번 가져 와서 실제로 요청을 엔드 M2M GW에 전송하지 않고도 모든 요청 애플리케이션들에 이 정보를 포워딩할 수 있다.

제2 예로서, ADDS는 애플리케이션 발견 또는 M2M 서비스 발견을 보조할 수 있다. M2M 애플리케이션이 ADDS에 등록할 때마다, ADDS는 애플리케이션에 대한 정보를 저장하고 모든 애플리케이션 타입들 및 그들의 상세사항에 관한 저장소를 유지할 수 있다. M2M 서비스 또는 M2M 애플리케이션을 찾기를 원하는 새로운 M2M 애플리케이션은 ADDS에 질의하여 서비스 또는 애플리케이션을 찾을 수 있다.

제3 예로서, M2M 디바이스 상의 애플리케이션은 통신을 확립할 것을 필요로 하는 SCS의 FQDN을 가질 수 있다. M2M 디바이스가 DNS 질의를 수행하는 것 대신에, 목적지 디바이스 식별자를 갖는 ADDS 메시지를 SCS FQDN으로서 전송할 수 있다. ADDS는 FQDN을 확인하고, 메시지를 SCS에 포워딩할 수 있다. 이 피쳐는 M2M 디바이스에서 DNS 확인 절차를 절감하며 무선을 통한 메시지의 수를 감소시킨다.

제4 예로서, ADDS는 SCS로부터 부트스트랩핑 파라미터를 수신하고 ADDS에 등록할 때 이것을 안전하게 M2M 애플리케이션에 전달할 수 있다.

예시적 노드 및 네트워크 엔티티 아키텍쳐

도 18은 UE(예를 들어, 도 1-4a-d의 UE들(104, 214, 312, 318)) 또는 다른 엔드 노드 디바이스 등의, ADDS 클라이언트(324)가 존재할 수 있는 예시적 엔드 노드(30)의 도면이다. 도 18에 도시된 바와 같이, 엔드 노드(30)는, 프로세서(32), 트랜시버(34), 전송/수신 요소(36), 스피커/마이크로폰(38), 키패드(40), 디스플레이/터치패드(42), 비착탈식 메모리(44), 착탈식 메모리(46), 전원(48), GPS(global positioning system) 칩셋(50), 및 기타의 주변기기(52)를 포함할 수 있다. 엔드 노드(40)는, 실시예와 일치되면서 전술된 요소들의 임의의 하위조합(sub-combination)을 포함할 수 있다는 것을 이해할 것이다.

프로세서(32)는, 범용 프로세서, 특별 목적 프로세서, 종래의 프로세서, 디지털 신호 처리기(DSP; digital signal processor), 복수의 마이크로프로세서, DSP 코어와 연계한 하나 이상의 마이크로프로세서, 제어기, 마이크로제어기, 주문형 집적 회로(ASIC; Application Specific Integrated Circuit), 필드 프로그래머블 게이트 어레이(FPGA; Field Programmable Gate Array) 회로, 기타 임의 타입의 집적 회로(IC), 상태 머신 등일 수 있다. 프로세서(32)는, 신호 코딩, 데이터 처리, 전력 제어, 입력/출력 처리, 및/또는 엔드 노드(30)가 무선 환경에서 동작할 수 있게 하는 기타 임의의 기능을 수행할 수 있다. 프로세서(32)는, 전송/수신 요소(36)에 결합될 수 있는 트랜시버(34)에 결합될 수 있다. 도 18은 프로세서(32)와 트랜시버(34)를 별개의 컴포넌트로서 도시하고 있지만, 프로세서(32)와 트랜시버(34)는 전자적 패키지 또는 칩 내에 함께 통합될 수도 있다는 것을 이해할 것이다. 프로세서(32)는 애플리케이션-계층 프로그램 예를 들어, 브라우저 및/또는 무선 액세스-계층(RAN) 프로그램 및/또는 통신을 수행할 수 있다. 프로세서(32)는, 인증, 보안 키 협의, 및/또는 예를 들어, 액세스-층 및/또는 애플리케이션 층에서 등의 암호 동작과 같은 보안 동작을 수행할 수 있다.

전송/수신 요소(36)는, 또 다른 피어에 신호를 전송하거나 이로부터 신호를 수신하도록 구성될 수 있다. 예를 들어, 한 실시예에서, 전송/수신 요소(36)는 RF 신호를 전송 및/또는 수신하도록 구성된 안테나일 수 있다. 전송/수신 요소(36)는, WLAN, WPAN, 셀룰러 등의, 다양한 네트워크 및 에어 인터페이스를 지원할 수 있다. 한 실시예에서, 전송/수신 요소(36)는, 예를 들어, IR, UV, 또는 가시광 신호를 전송 및/또는 수신하도록 구성된 방출기/검출기일 수도 있다. 역시 또 다른 실시예에서, 전송/수신 요소(36)는 RF 및 광 신호 양쪽 모두를 전송 및 수신하도록 구성될 수 있다. 전송/수신 요소(36)는 임의 조합의 무선 또는 유선 신호를 전송 및/또는 수신하도록 구성될 수 있다는 것을 이해할 것이다.

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

트랜시버(34)는, 전송/수신 요소(36)에 의해 전송되는 신호를 변조하고 전송/수신 유닛(36)에 의해 수신되는 신호를 복조하도록 구성될 수 있다. 앞서 언급한 바와 같이, 엔드 노드(30)는 멀티-모드 능력을 가질 수도 있다. 따라서, 트랜시버(34)는, 엔드 노드(30)가, 예를 들어, UTRA 및 IEEE 802.11 또는 802.15 등의 복수의 RAT을 이용하여 통신할 수 있게 하기 위한 복수의 트랜시버를 포함할 수 있다.

프로세서(32)는, 비착탈식 메모리(44) 및/또는 착탈식 메모리(46) 등의, 임의의 타입의 적절한 메모리로부터 정보를 액세스하거나, 여기에 데이터를 저장할 수도 있다. 비착탈식 메모리(44)는, 랜덤 액세스 메모리(RAM), 판독-전용 메모리(ROM), 하드 디스크, 또는 기타 임의 타입의 메모리 저장 디바이스를 포함할 수 있다. 착탈식 메모리(46)는, 가입자 신원 모듈(SIM; subscriber identity module), 메모리 스틱, 보안 디지털(SD; secure digital) 메모리 카드 등을 포함할 수 있다. 다른 실시예에서, 프로세서(32)는, 서버 또는 가정용 컴퓨터 등의, 엔드 노드(30)에 물리적으로 위치해 있지 않은 메모리로부터 정보를 액세스하거나, 여기에 데이터를 저장할 수도 있다.

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

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

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

도 19는, ADDS 엔티티 (322)가 구현될 수 있는 임의의 노드를 포함한 또는 네트워크에서 독립형 노드로서 동작하는 ADDS 엔티티(322)의 경우, 도 1-4a-d에 도시된 코어 네트워크 노드들 중 임의의 것을 구현하는 데 이용될 수 있는 컴퓨터 시스템 또는 서버의 블록도이다. 도 19의 컴퓨터 시스템 또는 서버는, 주로, 소프트웨어 형태일 수 있는 컴퓨터 판독가능한 명령어에 의해, 또는 심지어, 이러한 소프트웨어가 저장되거나 액세스되는 어떠한 수단에 의해 제어될 수 있다. 이러한 컴퓨터 판독가능한 명령어는 중앙 처리 유닛(CPU)(91) 등의 프로세서 내에서 실행되어 컴퓨터 시스템(90)이 작업을 수행하게 할 수 있다. 많은 공지된 워크스테이션, 서버 및 개인용 컴퓨터에서, 중앙 처리 장치(91)는 마이크로프로세서라 불리는 단일-칩 CPU에 의해 구현된다. 다른 머신들에서, 중앙 처리 유닛(91)은 복수의 프로세서를 포함할 수도 있다. 코프로세서(81)는, 추가적인 기능을 수행하거나 CPU(91)를 보조하는, 메인 CPU(91)와는 별개의, 선택사항적 프로세서이다. CPU(91) 및/또는 코프로세서(81)는, P2P 통신과 연계하여 데이터를 수신, 생성, 및 처리할 수 있다.

동작시, CPU(91)는, 명령어를 인출하고, 디코딩하고, 실행하며, 컴퓨터의 메인 데이터-전송 경로, 즉, 시스템 버스(80)를 통해, 정보를 다른 자원들에 전송하거나 이로부터 정보를 가져온다. 이러한 시스템 버스는 컴퓨터 시스템(90) 내의 컴포넌트들을 접속하고 데이터 교환을 위한 매체를 정의한다. 시스템 버스(80)는 통상적으로, 데이터를 전송하기 위한 데이터 라인, 주소를 전송하기 위한 주소 라인, 및 인터럽트를 전송하고 시스템 버스를 동작시키기 위한 제어 라인을 포함한다. 이러한 시스템 버스(80)의 예는 PCI(Peripheral Component Interconnect) 버스이다.

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

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

디스플레이 제어기(96)에 의해 제어되는 디스플레이(86)는 컴퓨터 시스템(90)에 의해 생성된 시각적 출력을 디스플레이하는 데 이용된다. 이러한 시각적 출력은, 텍스트, 그래픽, 애니메이트된 그래픽, 및 비디오를 포함할 수 있다. 디스플레이(86)는, CRT-기반의 비디오 디스플레이, LCD-기반의 평판 디스플레이, 개스 플라즈마-기반의 평판 디스플레이 또는 터치-패널로 구현될 수 있다. 디스플레이 제어기(96)는 디스플레이(86)에 전송되는 비디오 신호를 생성하는 데 요구되는 전자 컴포넌트를 포함한다. 또한, 컴퓨터 시스템(90)은, 컴퓨터 시스템(90)을 외부 통신 네트워크에 접속하는 데 이용될 수 있는 네트워크 어댑터(97)를 포함할 수 있다.

ADDS 클라이언트(324) 및 ADDS 엔티티(322)를 포함한, 여기서 설명된 시스템들, 방법들, 및 프로세스들 중 임의의 것 또는 전부는, 컴퓨터 판독가능한 저장 매체에 저장된 컴퓨터 실행가능한 명령어, 예를 들어, 프로그램 코드의 형태로 임베딩될 수 있고, 이 컴퓨터 실행가능한 명령어는, 컴퓨터, 서버, 피어, 프로세서 등의 머신에 의해 실행될 때, 여기서 설명된 시스템, 방법, 및 프로세스를 수행 및/또는 구현한다는 것을 이해할 것이다. 구체적으로는, 여기서 설명된 단계들, 동작들 또는 기능들 중 임의의 것은 이러한 컴퓨터 실행가능한 명령어의 형태로 구현될 수 있다. 컴퓨터 판독가능한 저장 매체는, 정보 저장을 위한 임의의 방법이나 기술로 구현된 휘발성 및 비휘발성의, 착탈식 및 비착탈식 매체를 포함하지만, 이러한 컴퓨터 판독가능한 저장 매체는 신호를 포함하지 않는다. 컴퓨터 저장 매체로서는, RAM, ROM, EEPROM, 플래쉬 메모리 또는 기타의 메모리 기술, CD-ROM, 디지털 다기능 디스크(DVD), 또는 기타의 광학 디스크 스토리지, 자기 카셋트, 자기 테이프, 자기 디스크 스토리지 또는 기타의 자기 저장 디바이스, 또는 컴퓨터에 의해 액세스될 수 있고 원하는 정보를 저장하는 데 이용될 수 있는 기타 임의의 물리적 매체가 포함되지만, 이것으로만 제한되는 것은 아니다.

Claims (21)

1. 네트워크의 제1 엔드 노드(end node)에서 실행중인 제1 애플리케이션이 제2 엔드 노드에서 실행중인 제2 애플리케이션에 메시지를 전송할 수 있는 통신 네트워크에서의 방법으로서, 상기 네트워크는 상기 메시지를 상기 제2 애플리케이션에 전송하는 데 이용될 수 있는 복수의 상이한 메시지 트랜스포트 메커니즘을 지원할 수 있으며, 상기 방법은,
   상기 제2 엔드 노드에서 실행중인 상기 제2 애플리케이션에 메시지를 전송하라는 요청 ―상기 요청은 상기 제2 애플리케이션의 고유 식별자를 포함함― 을 상기 제1 엔드 노드에서 실행중인 상기 제1 애플리케이션으로부터 수신하는 단계;
   상기 제1 애플리케이션에 관한 정보, 상기 제1 또는 제2 엔드 노드에 관한 정보, 또는 전송될 메시지에 관한 정보 중 적어도 하나에 기초하여, 상기 네트워크에 의해 지원되는 상기 복수의 상이한 메시지 트랜스포트 메커니즘 중 하나를 선택하는 단계; 및
   상기 선택된 트랜스포트 메커니즘을 이용하여 상기 제2 애플리케이션이 존재하는 상기 제2 엔드 노드에 상기 메시지를 전송하는 단계
   를 포함하는 방법.
2. 제1항에 있어서, 상기 복수의 상이한 메시지 트랜스포트 메커니즘은, SMS(Short Message Service) 트랜스포트 메커니즘, NAS(Non-Access Stratum) 트랜스포트 메커니즘, USSD(Unstructured Supplementary Service Data) 메커니즘, 또는 3GPP 네트워크의 사용자 평면 트랜스포트 메커니즘을 포함하는, 방법.
3. 제1항에 있어서, 상기 제1 및 제2 엔드 노드들 각각은, M2M 또는 MTC 디바이스 또는 게이트웨이, 머신, 센서, 기기(appliance), 이동국, 고정형 또는 모바일 가입자 유닛, 페이저, PDA(personal digital assistant), 컴퓨터, 모바일 전화, 스마트폰, SCS(Service Capability Server), M2M 서버, MTC 서버, SCL(Service Capability Layer), CSE(Common Services Entity) 또는 애플리케이션 서버(AS) 중 하나를 포함할 수 있는, 방법.
4. 제1항에 있어서, 상기 방법의 단계들은 상기 제1 엔드 노드에서 실행중인 논리적 엔티티에 의해 수행되는, 방법.
5. 제1항에 있어서, 상기 방법의 단계들은 코어 네트워크 노드에서 실행중인 논리적 엔티티에 의해 수행되는, 방법.
6. 제1항에 있어서, 상기 제1 애플리케이션에 관한 정보는, 메시지 레이트, QoS(quality-of-service) 요건, 지연 용인, 애플리케이션 가용성, 및 수락가능한 메시지 손실률 중 하나 이상을 포함하는, 방법.
7. 제1항에 있어서, 상기 메시지에 관한 정보는, 메시지 크기와 메시지 중요도 중 하나 이상을 포함하는, 방법.
8. 제1항에 있어서, 상기 제1 또는 제2 엔드 노드에 관한 정보는 엔드 노드 능력과 엔드 노드 가용성 중 하나 이상을 포함하는, 방법.
9. 제1항에 있어서, 복수의 상이한 메시지 트랜스포트 메커니즘을 지원하는 네트워크 접속에 대한 요청을 상기 제1 엔드 노드로부터 전송하는 단계를 더 포함하는 방법.
10. 제9항에 있어서, 상기 복수의 상이한 메시지 트랜스포트 메커니즘을 지원하는 네트워크 접속에 대한 요청은, 표시성 APN(Access Point Name) 또는 요청 플래그를 NAS 메시지에 포함시킴으로써 상기 네트워크에 표시되는, 방법.
11. 프로세서와 메모리를 포함하는 네트워크 노드로서, 상기 네트워크 노드는 네트워크 내의 엔드 노드들에서 실행되는 애플리케이션들 사이에서 메시지를 전송하는 데 이용될 수 있는 복수의 상이한 메시지 트랜스포트 메커니즘을 지원하는 통신 네트워크에 접속되고, 상기 네트워크 노드의 상기 메모리는, 상기 네트워크 노드의 상기 프로세서에 의해 실행될 때, 상기 네트워크 노드로 하여금,
    제1 애플리케이션으로부터, 상기 통신 네트워크의 엔드 노드에서 실행중인 제2 애플리케이션에 메시지를 전송하라는 요청 ―상기 요청은 상기 제2 애플리케이션의 고유 식별자를 포함함― 을 수신하는 단계;
    상기 제1 애플리케이션에 관한 정보, 상기 제2 애플리케이션이 존재하는 상기 엔드 노드에 관한 정보, 또는 전송될 메시지에 관한 정보 중 적어도 하나에 기초하여, 상기 네트워크에 의해 지원되는 상기 복수의 상이한 메시지 트랜스포트 메커니즘 중 하나를 선택하는 단계; 및
    상기 선택된 트랜스포트 메커니즘을 이용하여 상기 제2 애플리케이션이 존재하는 상기 엔드 노드에 상기 메시지를 전송하는 단계
    를 포함하는 단계들을 수행하게 하는 컴퓨터-실행가능한 명령어들을 저장하는, 네트워크 노드.
12. 제11항에 있어서, 상기 복수의 상이한 메시지 트랜스포트 메커니즘은, SMS(Short Message Service) 트랜스포트 메커니즘, NAS(Non-Access Stratum) 트랜스포트 메커니즘, USSD(Unstructured Supplementary Service Data) 메커니즘, 또는 3GPP 네트워크의 사용자 평면 트랜스포트 메커니즘을 포함하는, 네트워크 노드.
13. 제11항에 있어서, 상기 네트워크 노드는, M2M 또는 MTC 디바이스 또는 게이트웨이, 머신, 센서, 기기, 이동국, 고정형 또는 모바일 가입자 유닛, 페이저, PDA(personal digital assistant), 컴퓨터, 모바일 전화, 스마트폰, SCS(Service Capability Server), M2M 서버, MTC 서버, SCL(Service Capability Layer), CSE(Common Services Entity) 또는 애플리케이션 서버(AS) 중 하나를 포함하는, 네트워크 노드.
14. 제11항에 있어서, 상기 제1 애플리케이션은 상기 네트워크 노드에서 실행되는, 네트워크 노드.
15. 제11항에 있어서, 상기 네트워크 노드는 코어 네트워크 노드를 포함하는, 네트워크 노드.
16. 제11항에 있어서, 상기 제1 애플리케이션에 관한 정보는, 메시지 레이트, QoS(quality-of-service) 요건, 지연 용인, 애플리케이션 가용성, 및 수락가능한 메시지 손실률 중 하나 이상을 포함하는, 네트워크 노드.
17. 제11항에 있어서, 상기 메시지에 관한 정보는, 메시지 크기와 메시지 중요도 중 하나 이상을 포함하는, 네트워크 노드.
18. 제11항에 있어서, 상기 제2 애플리케이션이 존재하는 엔드 노드에 관한 정보는 엔드 노드 능력과 엔드 노드 가용성 중 하나 이상을 포함하는, 네트워크 노드.
19. 제11항에 있어서, 상기 네트워크에 의해 지원되는 상기 복수의 상이한 메시지 트랜스포트 메커니즘 중 하나를 선택하는 단계는 또한, 상기 네트워크 노드에 관한 정보에 기초하는, 네트워크 노드.
20. 제11항에 있어서, 상기 컴퓨터-실행가능한 명령어들은 또한, 상기 네트워크 노드로 하여금 복수의 상이한 메시지 트랜스포트 메커니즘을 지원하는 네트워크 접속에 대한 요청을 전송하게 하는, 네트워크 노드.
21. 제20항에 있어서, 복수의 상이한 메시지 트랜스포트 메커니즘을 지원하는 네트워크 접속에 대한 요청은, 상기 네트워크 노드가 표시성 APN(Access Point Name) 또는 요청 플래그를 NAS 메시지에 포함시키는 것에 의해 상기 네트워크에 표시되는, 네트워크 노드.

Images