KR101875607B1

KR101875607B1 - 이동통신 시스템에서의 ｍｔｃ 데이터 전송 방법

Info

Publication number: KR101875607B1
Application number: KR1020100107282A
Authority: KR
Inventors: 김현숙; 사소 스토자노브스키; 아르나우드 베드리느; 김태현; 김래영
Original assignee: 엘지전자 주식회사
Priority date: 2010-02-11
Filing date: 2010-10-29
Publication date: 2018-07-06
Also published as: KR20110093581A; KR101911277B1; KR20180076363A

Abstract

본 발명은 이동통신 시스템에 관한 것으로서, 특히 이동통신 시스템의 MTC (machine type communication) 서비스에서 제어평면(control plane)으로 작은 사이즈의 제어신호(일명, small data)를 전송하는 방법에 관한 것이다.
본 발명은, 패킷 데이터 베어러 설정을 하지 않고, 제어 신호(control signal) 상에서, 예를 들어 기존 제어 절차 또는 제어 메시지에 MTC 데이터를 캡슐화하고, 그 MTC 데이터가 캡슐화된 제어 신호를 네트워크에서 단말에 보냄으로써, 네트워크 자원의 효율을 최적화하고 또한 무선 채널의 부하를 줄이는 것이다.

Description

이동통신 시스템에서의 ＭＴＣ 데이터 전송 방법{METHOD FOR EFFICIENTLY TRANSMITTING SMALL DATA OF MACHINE TYPE COMMUNICATION IN MOBILE COMMUNICATIONS SYSTEM}

본 발명은 이동통신 시스템에 관한 것으로서, 특히 이동통신 시스템의 MTC (machine type communication) 서비스에서 제어평면(control plane)으로 작은 사이즈의 제어신호(일명, small data)를 전송하는 방법에 관한 것이다.

3세대 이동통신 시스템의 기술 규격을 제정하는 3GPP에서는 4세대 이동통신과 관련된 여러 포럼들 및 새로운 기술에 대응하기 위하여, 2004년 말경부터 3GPP 기술들의 성능을 최적화 시키고 향상시키려는 노력의 일환으로 LTE/SAE (Long Term Evolution/System Architecture Evolution) 기술에 대한 연구를 시작하였다. 3GPP SA WG2을 중심으로 진행된 SAE는 3GPP TSG RAN의 LTE 작업과 병행하여 네트워크의 구조를 결정하고 이 기종 망간의 이동성을 지원하는 것을 목적으로 하는 망 기술에 관한 연구이며, 최근 3GPP의 중요한 표준화 이슈들 중 하나이다. 이는 3GPP 시스템을 IP 기반으로 하여 다양한 무선 접속 기술들을 지원하는 시스템으로 발전 시키기 위한 작업으로, 보다 향상된 데이터 전송 능력으로 전송 지연을 최소화 하는, 최적화된 패킷 기반 시스템을 목표로 작업이 진행되어 왔다.

이하, 본 발명의 설명에서 사용되는 기술용어를 설명한다.

- MTC 기능은 MTC device간의 통신이나 MTC device와 MTC server 간의 통신을 지원하기 위한 기능으로써, 기존 사람 대 사람의 연결과 달리 중간에 사람의 개입 없이 통신이 이루어지는 것을 의미한다. 예를 들어, MTC application으로는 자동판매기와 서버, POS(Point of Service) 장치와 서버, 전기나 수도 검침기와 서버 간의 통신들을 들 수 있다. 여기서 해당 장치를 MTC device라고 한다. 여기서, MTC 란 Machine to Machine이나 사물통신의 이름으로 불리기도 한다

- TA (tracking area)는 E-UTRAN이 서비스를 제공하는 지역을 가리키며 하나 또는 다수의 E-UTRAN 셀(cell)을 포함한다.

- RA (routing area)는 GERAN/UTRAN이 서비스를 제공하는 지역을 가리키며 하나 또는 다수의 GERAN/UTRAN 셀을 포함한다.

- TAI(Tracking Area Identity) 리스트는, 트래킹 지역(tracking area) 업데이트 절차를 수행하지 않고 단말이 진입할 수 있는 트래킹 지역들을 식별하는 각 TA 식별자(즉, TAI: tracking area identity)의 리스트들을 가리킨다 (A list of TAIs that identify the tracking areas that the UE can enter without performing a tracking area updating procedure. The TAIs in a TAI list assigned by an MME to a UE pertain to the same MME area). TAI 리스트에 대한 상세한 설명은 표준문서 3GPP TS 24.301 v9.1.0 에 개진된 사항을 원용한다.

- 이동성 관리 엔티티 지역 (MME area): MME 지역은 MME가 서비스하는 네트워크의 일부 지역을 가리킨다. MME 지역은 하나 또는 다수의 트래킹 지역 (TA: tracking area)들로 구성된다. 또한, 하나의 기지국 (즉, eNodeB)가 서비스하는 모든 셀은 하나의 MME 지역에 포함된다 (The MME (mobility management entity) area is the part of the network served by an MME. An MME area consists of one or several Tracking Areas. All cells served by an eNodeB are included in an MME Area.) MME 지역에 대한 상세한 설명은 표준문서 3GPP TS 23.002 v9.2.0 에 개진된 사항을 원용한다.

- UMTS : Universal Mobile Telecommunication System으로 3G 망을 의미한다.

- EPS : Evolved Packet System으로 LTE access 네트워크를 지원하는 핵심망(core network)이다. 또한, EPS는 UMTS가 진화된 형태의 망이다.

- NodeB : UMTS 망의 Base station 으로 옥외에 설치하며 coverage는 macro cell 규모

- eNodeB : EPS 망의 기지국(Base station)으로 옥외에 설치하며, 서비스 커버리지는(coverage)는 마이크로 셀(macro cell) 규모이다.

- UE : User Equipment, 단말 장치를 의미한다.

- IMSI : International Mobile Subscriber Identity 로써 이동통신망에서 국제적으로 유일하게 할당된 사용자의 고유 식별자(id)이다.

- SIM card : Subscriber Identity Module 로써 IMSI와 같은 사용자 가입자 정보 등이 포함되어 있다.

- UICC : Universal Integrated Circuit Card로써 SIM card와 같은 의미로 사용된다.

- MTC : Machine Type Communication으로 사람의 개입 없이 장치간에 일어나는 통신을 의미한다.

- MTC 장치(device) : 핵심망(Core network)를 통한 통신기능이 있는 특정 목적을 수행하는 단말(UE)로서, 예를 들어, 자판기, 검침기 등이 있다.

- MTC 서버(server) : MTC device를 관리하고 데이터를 주고 받는 네트워크 상의 서버. 이는 core network 외부에 있을 수 있다.

- MTC 어플리케이션(application) : MTC device와 MTC Server를 이용한 실제 응용으로서, 원격 검침, 물량 이동 추적 등이 예이다.

- MTC 기능(Feature) : MTC application을 지원하기 위한 네트워크의 기능이나 특징, 즉, 각 application의 용도에 따라 일부 feature들이 요구된다. 예를 들어 MTC 감시(monitoring) (장비 분실에 대비한 원격 검침 등에 필요), Low mobility(자판기의 경우 이동이 거의 없다.) 등이 있다.

- RAN : Radio Access Network로써 RNC, NodeB, eNodeB 와 같은 3GPP무선 Access를 총칭한다.

- HLR(Home Location Register)/HSS (Home Subscriber Server): 3GPP 네트워크내의 가입자 정보를 나타내는 데이터베이스(DB)이다.

- RANAP : Radio Access Network Application Part 의 약자로 RAN과 핵심망(core network)의 제어(control)를 담당하는 노드 (MME/SGSN/MSC) 사이의 인터페이스를 의미한다.

- 셀 캠핑 (또는 캠프) 온 (Cell camping on) 상태란, 단말이 셀 선택 절차 또는 셀 재선택 절차(cell selection/reselection process)를 마치고 셀(cell)을 선택한 상태를 말한다. 이에 대한 상세한 설명은 표준문서 3GPP TS 36.304 v9.1.0 에 개진된 사항을 원용한다.

- ISR(Idle mode Signaling Reduction)는, 예를 들어 E-UTRAN 네트워크와 UTRAN/GERAN 과 같이 서로 다른 접속 네트워크 (access network)를 단말이 이동하는 경우 위치등록을 위한 시그널링을 줄여 네트워크 자원의 효율을 높여주는 서비스이다.

- ICS(IMS Centralized Services)는, 단말이 어태취(attach)되어 있는 접속네트워크 (access network)에 상관없이, (즉, IP-CAN 뿐만 아니라 CS 도메인에 어태취(attach)되어 있더라도) IMS로 안정되게 일정한 (consistent)한 서비스를 제공한다. ICS에 대한 상세한 설명은 표준문서 3GPP TS 23.292 v9.4.0 에 개진된 사항을 원용한다.

- IMS(IP Multimedia Subsystem)는, 멀티미디어 서비스를 IP 기반으로 제공하는 시스템을 말한다.

- 어태취(attach)란, 단말이 네트워크 노드와 접속하는 것을 말하는 것으로써, 넓은 의미로 핸드오버(handover)시 발생하는 어태취도 포함하는 의미이다.

이상, 설명한 기술용어를 참조하여 본 발명을 설명한다.

도 1은 MTC 지원을 위한 3GPP 서비스 모델을 도시한 개념도이다.

MTC 지원을 위해 3GPP 표준의 GSM/UMTS/EPS에서는 PS 망을 통해 통신하는 것으로 정의되어 있으나, 본 발명은 CS 망에 대해서도 적용 가능한 방법을 기술한다. 한다. 현재의 기술 규격에서 망구조에 대한 정의는 3GPP의 기존 베어러(bearer)를 이용하는 것이 제안되어 있다. 한편, MTC 장치(device)와 MTC 서버 간의 데이터 교환을 위해 SMS (short message service)를 사용하는 방법은 대안 해결책(alternative solution) 중 하나로 제안되었다. 이는 MTC 응용(application)의 특성상 검침 정보나 제품 정보 등 적은 량의 디지털 데이터들이 그 대상이 될 것을 고려하여 SMS를 이용하는 것이 제안되었고, 그 방식으로 기존의 SMS 방식과 IMS에 기반한 SMS 방식이 지원 가능하다. 도 1에서, MTCsms는 기존 SMS 방식을 통한 데이터 교환 인터페이스이며, MTCi는 3GPP bearer 서비스 및 IMS 를 위한 데이터 교환 인터페이스이다.

도 2는 종래 데이터 전송방식으로서, E-UTRAN 초기 어태취 절차(initial attach procedure)를 도시한 신호 흐름도이다. 도 2는 EPC에 적용된 예로써, TS 23.401 v9.3.0 (2009-12) clause 5.3.2.1 E-UTRAN initial attach procedure 을 간략하게 나타낸 것이다. 여기서, 어태취 절차(Attach procedure)는 일반적으로 처음 E-UTRAN 셀(cell)에 들어갔을 때, EPC에 연결(connection)을 시도할 때 사용된다. 또한, 어태취 절차(Attach procedure)는 non-3GPP 억세스(access)로부터 E-UTRAN으로 핸드오버(handover)된 경우에도 사용될 수 있다.

이하, 도 2를 참조하여 설명한다.

단말(10)로부터 attach request 메시지가 eNB(20)를 경유하여 MME(30)로 전달된다(S2-1 ~ S2-2). HHS(70)를 통해 단말(10)의 인증 절차를 수행한다(S2-3).

그리고, HSS(70)에 단말(10)의 위치 정보를 등록한다(S2-4). MME(30)는 S-GW(40)로 디폴트 베어러(default bearer) 생성을 요청하며(S2-5), S-GW(40)와 P-GW(50) 사이에도 디폴트 베어러(default bearer) 생성을 위한 메시지가 교환된다(S2-6 및 S2-8). 필요에 따라, 사업자 정책(operator policy)를 위한 PCRF 상호작용(interaction)이 P-GW(50)와 PCRF(60) 사이에 수행된다(S2-7). P-GW(50)와 S-GW(40)사이에 디폴트 베어러(default bearer)가 형성되고, 이 단계에서 S-GW와 P-GW는 데이터 전달을 위한 TEID를 교환한다. 이때, 핸드오버(handover)를 위한 어태취(attach)가 아니라면 (즉, initial attach), P-GW(50)에서 S-GW(40)로 다운링크 데이터(downlink data)가 전달되기 시작한다. 한편, TEID (Tunnelling Endpoint ID)는 기술적으로 데이터 전달을 위한 주소와 같은 역할을 하는 파라미터이다. TEID 정보를 알고 있어야만 데이터 전송이 가능하다.

어태취 허용(Attach accept) 메시지가 MME(30)에서 eNB(20)로 전달되며, 이때 S-GW(40)의 TEID를 포함한다(S2-10). 또한 이 메시지는 RAN 구간의 무선자원 설정(setup)을 개시(initiation) 시킨다.

RRC 연결 재구성(RRC connection reconfiguration)을 통해 무선구간의 자원이 설정(setup)되며, 그 결과가 eNB(20)로 전달된다(S2-11).

단말(10)로부터 어태취 완료(Attach complete)메시지가 eNB(20)를 경유하여 MME(30)로 보내지며(S2-13 ~ S2-14), 이때 eNB(20)는 다운링크 데이터(downlink data) 수신을 위한 eNB TEID를 함께 전달한다. 또한, 이때부터 eNB(20)를 경유하여 S-GW(40)로 업링크 데이터(uplink data)가 전달될 수 있다.

MME(30)는 수정 베어러 요청(Modify bearer request) 메시지를 통해 eNB TEID를 S-GW(40)로 전달한다(S2-15). 필요에 따라 S-GW(40)와 P-GW(50) 사이의 베어러가 갱신(update) 된다(S2-16 ~ S2-17). 이후부터 다운링크 데이터(down link data)가 eNB(20)를 경유하여 단말(10)에게 전달될 수 있다.

필요에 따라, 이후 non-3GPP 억세스(access)로의 mobility를 위해 APN, PDN GW id등을 HSS(70)에 저장해둬야 할 필요가 있을 경우, MME(30)는 통지 요청(Notify Request) 메세지를 통해 HSS(70) 등록 과정을 거친다(S2-19).

도 3은 트레킹 지역 갱신 절차(TAU: tracking area update procedure)를 도시한 신호 흐름도이다. 도 3는 EPC에 적용된 예로써 TS 23.401 v9.3.0 (2009-12) clause 5.3.3.1/5.3.3.2 TAU procedure 을 간략하게 보여주고 있다. TAU는 일반적으로 idle mode 상태의 UE가 새로운 위치 등록을 시도할 때 수행된다.

이하, 도 3을 참조하여 설명한다. 다만, 도 3에서 S-GW/P-GW(51)는, 설명의 편의상, S-GW와 P-GW 의 네트워크 요소를 통합하여 표시한 것일 뿐, 그 표기로 인하여 네트워크의 구성 및 기능을 한정하는 것이 아니다.

단말(10)로부터 TAU 요청 메시지(TAU request)가 eNB(20)를 경유하여 MME(30)로 전달된다(S3-1 ~ S3-2).

MME(30)는 old MME(31)에게 해당 단말(10)의 컨텐스트 요청(context request) 메시지를 보내고, 베어러(bearer) 관련 정보 및 가입자 정보 등 해당 단말(10)의 컨텍스트(context) 정보를 받는다(S3-3 ~ S3-4). 그리고, MME(30)은 old MME(31)에게 컨텍스트 응답 메시지(context response)에 대한 컨텍스트 인정(context acknowledge)을 전송한다(S3-6). 한편, MME(30)는 HHS(70)를 통해 단말(10)의 인증 및 보안(security) 절차를 수행한다(S3-5).

Step 7~9: MME(30)는 S-GW/P-GW(51)로 Create Session Request 메시지를 통해 베어러(bearer) 생성을 요청하며, 만약 S-GW가 변경되지 않는 경우라면 MME(30)는 S-GW로 Update Bearer request 메시지를 보낸다(S3-7). 필요에 따라, S-GW와 P-GW(51) 사이에도 Modify bearer request/response 메시지가 교환된다(도 3에 미도시). 만약 다이나믹 (dynamic) PCC를 사용하게 되는 경우, 사업자 정책(operator policy)를 위한 PCRF 상호작용(interaction)이 P-GW와 PCRF 사이에 수행된다.

MME(30)는 해당 단말(10)에 대한 새로운 위치 등록을 위해 HSS(70)에 위치 갱신(location update)를 요청하며(S3-10), HSS(70)는 취소 위치 요청/응답(cancel location request/response) 메시지를 통해 old MME(31)에게 해당 단말(10)의 베어러 정보를 지우도록 요청한다(S3-11). HSS(70)는 MME(30)에게 갱신 위치 ACK (update location ACK)을 전달함으로써 새로운 위치 등록 과정을 마친다(S3-12).

TAU accept 메시지는 NAS 메시지 형태로 eNB(20)를 경유하여 MME(30)에서단말(10)에게 전달된다(S3-13).

도 4는 단말 트리거 서비스 요청 절차(UE triggered service request procedure)를 도시한 신호 흐름도이다. 도 4는 EPC에 적용된 예로써 TS 23.401 v9.3.0 (2009-12) clause 5.3.4.1 UE triggered Service Request procedure 을 간략하게 보여주고 있다. 여기서, 단말 트리거 서비스 요청 절차(UE triggered Service Request procedure)는 일반적으로 단말(10)이 개시(initiation)하여 새로운 서비스를 시작하거나, 페이징(paging)의 응답(response)으로써 업링크 데이터(uplink data)를 전송하고자 할 때 수행된다.

이하, 도 4를 참조하여 설명한다.

단말(10)로부터 NAS 메시지 형태의 서비스 요청(Service request) 메시지가 eNB(20)를 경유하여 MME(30)로 전달된다(S4-1 ~ S4-2). 한편, MME(30)는 HHS(70)를 통해 단말(10)의 인증 절차를 수행한다.

MME(30)는 S1-AP 프로토콜(protocol)을 이용한 초기 컨텍스트 설정 요청(Initial Context Setup Request) 메시지를 RAN 구간의 무선자원 설정(setup)을 개시(initiation) 시킨다(S4-4). 이때, 업링크 데이터(uplink data) 전송을 위한 S-GW(40)의 TEID가 eNB(20)로 전달된다. 그리고, 단말(10)과 eNB (20) 간의 무선구간에서는 무선 베어러(radio Bearer)가 생성된다(S4-5). 이때부터 단말(10)은 업링크 데이터(uplink data) 전송이 가능하다.

eNB(20)는 MME(30)로 초기 컨텍스트 설정 완료(initial Context Setup Complete) 메시지를 전송하고, 또한 다운링크 데이터(down link data) 전송이 가능하도록 eNB TEID를 함께 보낸다(S4-6).

수정 베어러 요청(Modify bearer request)를 통해 eNB TEID를 S-GW(40)로 전달하며, 다운링크 데이터 베어러(down link data bearer) 정보를 갱신한다(S4-7 및 S4-11). 한편, 필요에 따라 S-GW(40)와 P-GW(50) 사이의 베어러(bearer)가 갱신(update) 된다(S4-8 및 S4-10). 만약 다이나믹 PCC(dynamic PCC)를 사용하게 되는 경우, 사업자 정책(operator policy)를 위한 PCRF 상호작용(interaction)이 P-GW(50)와 PCRF(60) 사이에 수행된다(S4-9).

종래 GSM/UMTS/EPS와 같은 3GPP 시스템은 종단 사용자(end-user) 간, 즉 사람들 간의 통신을 위해 정의되었다. 그런데, 이러한 종래 이동통신 시스템은 MTC 장치와 MTC 서버 간의 통신에는 효과적이지 않으며, 또한 최적화된 통신 해결책이 아니다. 따라서, 최근 3GPP에서 MTC 장치와 MTC 서버 간에 데이터를 주고 받기 위한 기능 및 메커니즘을 정의하기 시작하였으나, 구체적인 방법은 여전히 미흡한 실정이다. 특히, MTC에서 많은 장치가 동시에 작은 크기의 데이터(일명, ‘small data’라 한다)를 전송하는 상황에서 네트워크의 부하를 증가시키게 된다. 왜냐하면, 도 1 내지 도 4에서 설명한 바와 같이, 작은 크기의 데이터(즉, small data)를 전송할지라도, 그 스몰 데이터 전송을 위한 패킷 데이터 베어러(bearer)의 설정(setup)이 필요하기 때문이다. 즉, UMTS의 경우 어태취 절차를 수행한 후, 데이터 전송 시 PDP 컨텍스트 활성화 절차(PDP context activation procedure)를 수행해야 한다. 그리고, EPC의 경우 어태취 절차에서 디폴트 베어러(default bearer) 가 설정되며, 어태취 종료 후, 추가적으로 특정 용도로 전용 베어러 설정(dedicated bearer setup)을 수행 하기도 한다. 이와 같이, 종래의 사용자 데이터 전송 방식은 패킷 데이터 베어러 설정이 필요하기 때문에, 베어러 설정에 소요되는 시간 지연이 크고, 전송해야하는 데이터의 양이 적은 경우 그 데이터 양에 비해 제어 시그널링 오버헤드(control signalling overhead)가 크다는 기술적 한계점이 있다.

따라서, 본 발명은 작은 크기의 데이터를 전송 시, 보다 간단하고 효과적인 방법을 제안한다. 본 발명은 제어 신호(control signal)에 MTC 사용자 데이터(즉, 스몰 데이터)를 캡슐화 (encapsulation)하여, MTC 특징(feature) 중 online/offline으로 스몰 데이터를 효과적으로 전송하는 방법을 제공한다. 단, 여기서 말하는 MTC 사용자 데이터는 실제 사용자 데이터(user data) (예를 들어, 장치(device)에서 수집한 보고 정보(reporting information)) 혹은 MTC를 위한 MTC 장치와 MTC 서버(server) 간의 제어 데이터(control data) (예를 들어, 보고 기간(reporting period)) 일 수 있다.

상기와 같은 목적을 달성하기 위하여 본 발명에 따른 이동통신시스템에서의 데이터 전송 방법은, (A) MTC(machine type communication) 데이터가 캡슐화되어 있는 제어 시그널링 메시지를 단말로부터 수신하는 단계와; (B) 상기 제어 시그널링 메시지에서 상기 MTC 데이터를 추출하는 단계와; (C) 상기 추출한 MTC 데이터를 MTC 서버로 전송하는 단계를 포함하는 것을 특징으로 한다.

바람직하게는, 상기 (B) 단계는

상기 수신한 제어 시그널링 메시지에 캡슐화된 MTC 데이터가 있는지 판단하는 단계를 더 포함하는 것을 특징으로 한다.

바람직하게는, 상기 (B) 단계에서

상기 수신한 제어 시그널링 메시지에 상기 MTC 데이터가 캡슐화되어 있음을 가리키는 인디케이터가 있는지 확인하여, 상기 캡슐화된 MTC 데이터가 있는 것으로 판단하는 것을 특징으로 한다.

바람직하게는, 상기 (B) 단계에서

상기 수신한 제어 시그널링 메시지에 상기 MTC 데이터의 컨텐츠 필드가 있는지 확인하여, 상기 캡슐화된 MTC 데이터가 있는 것으로 판단하는 것을 특징으로 한다.

바람직하게는, 상기 (B) 단계에서

상기 MTC 데이터가 캡슐화되어 있음을 가리키는 인디케이터 필드와, 상기 MTC 데이터의 컨텐츠 필드 모두가 상기 수신한 제어 시그널링 메시지에 존재하는 경우, 상기 캡슐화된 MTC 데이터가 있는 것으로 판단하는 것을 특징으로 한다.

바람직하게는, 상기 인디케이터 필드는 ‘protocol discriminator’이고,

상기 MTC 데이터의 컨텐츠 필드는 ‘protocol configuration options’인 것을 특징으로 한다.

바람직하게는, 상기 제어 시그널링 메시지는 제어 평면(control plane) 상의 메시지이고,

상기 제어 시그널링 메시지는 상기 단말이 네트워크에 어태취하는 절차 상의 메시지, 페이징 응답 메시지, 위치 등록 메시지, 또는 트리거 서비스 절차(triggered service procedure) 상의 메시지 중 하나인 것을 특징으로 한다.

바람직하게는, 상기 제어 시그널링 메시지는

상기 MTC 데이터가 캡슐화되어 포함되어 있음을 가리키는 인디케이터 필드와, 상기 MTC 데이터의 컨텐츠 필드 중 적어도 하나 또는 모두를 포함하는 것을 특징으로 한다.

바람직하게는, 상기 제어 시그널링 메시지에 대한 허용 또는 거절 메시지를 상기 단말에게 전달할 때, 상기 MTC 데이터에 대한 Ack 정보를 포함하여 전달하는 단계;를 더 포함하는 것을 특징으로 한다.

바람직하게는, 상기 MTC 데이터에 대한 상기 Ack 정보는

상기 단말로부터 상기 캡슐화된 MTC 데이터를 성공적으로 수신하였음;

상기 MTC 데이터를 추출하여 상기 MTC 서버로 전송하였음;

상기 MTC 서버가 상기 추출한 MTC 데이터를 성공적으로 수신되었음을 확인;

상기 MTC 데이터 추출 등의 실패로, 상기 단말에게 재전송이 필요함을 요청하는 의미;

상기 단말에게 보고할 사항;

중 적어도 하나를 포함하는 것을 특징으로 한다.

바람직하게는, 상기 MTC 서버로 전송한 상기 추출한 MTC 데이터에 대한 응답을 상기 MTC 서버로부터 수신하는 단계를 더 포함하는 것을 특징으로 한다.

상기와 같은 목적을 달성하기 위하여 본 발명에 따른 이동통신시스템에서의 데이터 전송 방법은,

(a) MTC(machine type communication) 데이터가 캡슐화되어 있는 서비스 요청 메시지(service request message)를 단말로부터 수신하는 단계와;

(b) 상기 서비스 요청 메시지가 상기 캡슐화 MTC 데이터 만을 전송하기 메시지인지를 판단하는 단계와;

(c) 상기 서비스 요청 메시지에서 상기 MTC 데이터를 추출하는 단계와;

(d) 상기 추출한 MTC 데이터를 MTC 서버로 전송하는 단계를 포함하는 것을 특징으로 한다.

바람직하게는, 상기 (b) 단계에서

상기 서비스 요청 메시지가 상기 캡슐화 MTC 데이터 만을 전송하는 용도의 메시지로 판단되는 경우,

상기 단말에 서비스하고 있는 기지국에 서비스 해제 명령을 전송하여, 상기 단말과 상기 기지국 간에 RRC 연결을 해제시키는 단계를 포함하는 것을 특징으로 한다.

바람직하게는, 상기 서비스 요청 메시지는

상기 MTC 데이터가 캡슐화되어 있음을 가리키는 인디케이터 필드와,

상기 서비스 요청 메시지가 상기 캡슐화 MTC 데이터 만을 전송하는 용도의 메시지인 것을 가리키는 인디케이터 필드 중 적어도 하나를 포함하는 것을 특징으로 한다.

바람직하게는, 상기 서비스 요청 메시지는

상기 MTC 데이터가 존재하고 있음을 함축적으로 가리키는 상기 MTC 데이터의 컨텐츠 필드 만을 포함하는 것을 특징으로 한다.

바람직하게는, 상기 제어 시그널링 메시지에 대한 허용 또는 거절 메시지또는 단말과 상기 기지국 간에 RRC 연결을 해제시키는 단계의 메시지를 상기 단말에게 전달할 때, 상기 MTC 데이터에 대한 Ack 정보를 포함하여 전달하는 단계;를 더 포함하는 것을 특징으로 한다.

바람직하게는, 상기 MTC 데이터에 대한 상기 Ack 정보는

상기 MTC 데이터를 추출하여 상기 MTC 서버로 전송하였음;

상기 단말에게 보고할 사항;

중 적어도 하나를 포함하는 것을 특징으로 한다.

본 발명은, MTC 특징(feature) 중 online/offline으로 스몰 데이터를 캡슐화 (encapsulation)하여, 제어 신호(control signal) 상에 전송함으로써, 무선 자원을 최적화시키고, 기존의 절차와 메시지의 활용을 극대화하는 효과가 있다.

또한, 본 발명은 종래 패킷 데이터 베어러를 사용할 때와 비교하여, 시스템의 부하를 줄이는 효과가 있다.

도 1은 MTC 지원을 위한 3GPP 서비스 모델을 도시한 개념도이다.
도 2는 종래 데이터 전송방식으로서, E-UTRAN 초기 어태취 절차(initial attach procedure)를 도시한 신호 흐름도이다.
도 3은 트레킹 지역 갱신 절차(TAU: tracking area update procedure)를 도시한 신호 흐름도이다.
도 4는 단말 트리거 서비스 요청 절차(UE triggered service request procedure)를 도시한 신호 흐름도이다.
도 5는 본 발명의 일 실시 예로서, 단말이 온라인 상태 또는 휴지 모드(idle mode) 상태 여부에 따라 MTC 데이터를 전송하기 위한 절차를 선택하는 방법을 도시한 흐름도이다.
도 6은 본 발명의 일 실시 예로서, TAU 요청 메시지에 MTC 데이터를 캡슐화시키는 방법이 적용된 TAU 요청 메시지(TAU request message)의 구성을 나타내는 표이다.
도 7은 ‘Protocol discriminator’ 인디케이터의 값을 도시한 표이다.
도 8은 ‘Protocol configuration options’필드의 information element를 도시한 것이다.
도 9는 본 발명의 일 실시 예로서, MTC 데이터의 크기가 정의된 기준 길이보다 큰 경우에 처리하는 방법을 도시한 흐름도이다.
도 10은 본 발명의 일 실시 예로서, 단말이 TAU 절차를 이용하여 MTC 데이터를 캡슐화하여 네트워크로 전송하는 방법을 도시한 신호 흐름도이다.
도 11은 본 발명의 일 실시 예로서, 단말이 서비스 요청 절차를 이용하여 MTC 데이터를 캡슐화하여 네트워크로 전송하는 방법을 도시한 신호 흐름도이다.

본 발명은 MTC(machine type communication)를 이용하는 이동통신 시스템에 적용된다. 그러나, 본 발명은 이에 한정하지 않고, 본 발명의 기술적 사상이 적용될 수 있는 차세대 이동통신 및 다른 유무선 통신에 적용될 수도 있다.

본 발명은 다양한 변경을 가할 수 있고 여러 가지 실시 예를 가질 수 있는 바, 특정 실시 예들을 도면에 예시하고 상세한 설명에 상세하게 설명하고자 한다. 그러나, 이는 본 발명을 특정한 실시 형태에 대해 한정하려는 것이 아니며, 본 발명의 사상 및 기술 범위에 포함되는 모든 변경, 균등물 내지 대체물을 포함하는 것으로 이해되어야 한다.

제1, 제2 등과 같이 서수를 포함하는 용어는 다양한 구성요소들을 설명하는데 사용될 수 있지만, 상기 구성요소들은 상기 용어들에 의해 한정되지는 않는다. 상기 용어들은 하나의 구성요소를 다른 구성요소로부터 구별하는 목적으로만 사용된다. 예를 들어, 본 발명의 권리 범위를 벗어나지 않으면서 제1 구성요소는 제2 구성요소로 명명될 수 있고, 유사하게 제2 구성요소도 제1 구성요소로 명명될 수 있다. 및/또는 이라는 용어는 복수의 관련된 기재된 항목들의 조합 또는 복수의 관련된 기재된 항복들 중의 어느 항목을 포함한다.

어떤 구성요소가 다른 구성요소에 "연결되어" 있다거나 "접속되어" 있다고 언급된 때에는, 그 다른 구성요소에 직접적으로 연결되어 있거나 또는 접속되어 있을 수도 있지만, 중간에 다른 구성요소가 존재할 수도 있다. 반면에, 어떤 구성요소가 다른 구성요소에 "직접 연결되어" 있다거나 "직접 접속되어" 있다고 언급된 때에는, 중간에 다른 구성요소가 존재하지 않는 것으로 이해되어야 할 것이다.

본 출원에서 사용한 용어는 단지 특정한 실시 예를 설명하기 위해 사용된 것으로, 본 발명을 한정하려는 의도가 아니다. 단수의 표현은 문맥상 명백하게 다르게 뜻하지 않는 한, 복수의 표현을 포함한다. 본 출원에서, "포함하다" 또는 "가지다" 등의 용어는 명세서 상에 기재된 특징, 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 거이 존재함을 지정하려는 것이지, 하나 또는 그 이상의 다른 특징들이나, 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것들의 존재 또는 부가 가능성을 미리 배제하지 않는 것으로 이해되어야 한다.

다르게 정의되지 않는 한, 기술적이거나 과학적인 용어를 포함해서 여기서 사용되는 모든 용어들은 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자에 의해 일반적으로 이해되는 것과 동일한 의미를 가지고 있다. 일반적으로 사용되는 사전에 정의되어 있는 것과 같은 용어들은 관련 기술의 문맥 상 가지는 의미와 일치하는 의미를 가지는 것으로 해석되어야 하며, 본 출원에서 명백하게 정의하지 않는 한, 이상적이거나 과도하게 형식적인 의미로 해석되지 않는다.

본 발명에 따른 단말은, 본 발명의 기술적 특징을 수행할 수 있는 모든 장치를 지칭한다. 즉, 본 발명에 따른 MTC 서비스 기능을 수행할 수 있는 이동통신 단말(예를 들어, 심장박동기, 자동판매기, 전력계량기, 공기 오염도 측정기 등등) UE(User Equipment)이며, 그 외도 인간 중심의 장치들(예를 등어, 핸드폰, 휴대폰, DMB 폰, 게임폰, 카메라폰, 스마트폰 등등)과, 그 이외 노트북, 데스크탑 컴퓨터(desktop computer), 랩탑 컴퓨터(laptop computer), 팸탑 컴퓨터(palmtop computer), PDA(personal digital assistant), 백색 가전 제품 등도 포함하는 포괄적인 의미이다.

이하, 첨부한 도면들을 참조하여 본 발명에 바람직한 실시 예를 상세히 설명하기로 하며, 첨부 도면을 참조하여 설명함에 있어 도면 부호에 상관없이 동일하거나 대응하는 구성요소는 동일한 참조번호를 부여하고 이에 대한 중복되는 설명은 생략하기로 한다.

본 발명의 기본 개념은: 패킷 데이터 베어러 설정을 하지 않고; 제어 신호(control signal) 상에서, 예를 들어 기존 제어 절차 또는 제어 메시지에 MTC 데이터를 캡슐화하고; 그 MTC 데이터가 캡슐화된 제어 신호를 네트워크와 단말 사이에 보냄으로써; 네트워크 자원의 효율을 최적화하고 또한 무선 채널의 부하를 줄이는 것이다.

본 발명의 일 예로서, MTC 데이터를 위치 갱신 메시지(예를 들어, TAU/RAT 절차, 등)에 캡슐화하여 전송하는 실시 예와, 서비스 요청 메시지(예를 들어, UE triggered Service Request)에 캡슐화하여 전송하는 실시 예를 설명한다.

또한, 본 발명에서, 단말이 여러 가지 절차(procedure) 중 MTC 데이터(일명, small data)를 캡슐화(encapsulation) 시키기 위해 선택하는 절차는 미리 사전에 구성(pre-configuration)되어 있거나 또는 다이나믹(dynamic)하게 변경될 수 있다. 예를 들어, 단말이 네트워크로 전송할 MTC 데이터를 캡슐화에 사용할 절차 내지 조건의 예는 다음과 같다: 즉, 사업자 정책(Operator policy); 사용자 선호도(User preference); 사용자 가입정보(User subscription); 해당 MTC 서비스/응용(services/application)의 특성; 단말의 능력(capability); 단말의 상태(status); 기타 radio 조건 (무선구간 환경) 등이 있다.

도 5는 본 발명의 일 실시 예로서, 단말이 온라인 상태 또는 휴지 모드(idle mode) 상태 여부에 따라 MTC 데이터를 전송하기 위한 절차를 선택하는 방법을 도시한 흐름도이다.

도 5를 참조하면, 단말이 MTC 업링크로 전송할 데이터(예를 들어, 단말의상태를 보고하는 small data)가 발생하였다고 가정할 때(S1), 현재 단말의 상태가 온라인 상태가 아니라면, 단말은 네트워크에 어태취 절차를 수행하여야 할 것이다. 따라서, 단말은 네트워크에 어태취 절차를 수행할 때, MTC 데이터를 캡슐화하여 네트워크(즉, MTC 서버)로 전송한다(S2 ~ S3).

한편, 단말이 온라인 상태이고, 휴지모드(idle mode) 상태이라면(S4), 여러 가지 절차가 선택될 수 있을 것이다. 즉, 단말이 일정시점 안에 정상적인 TAU 수행하는 경우(S5), 단말은 TAU 절차를 이용하여 MTC 데이터를 캡슐화하여 전송할 것이다(S6). 반면, 즉, 단말이 일정시점 안에 정상적인 TAU 수행하지 않는 경우(S5), 단말은 캡슐화된 MTC 데이터를 전송하기 위한 SR 절차의 개시하고, MTC 데이터를 전송 후, 절차를 중단한다(S7 ~ S8). 한편, 단말이 휴지 상태이고(S4) 일정 시점 안에 정상적인 SR이 발생한다면(S9), 단말은 SR 절차를 이용하여 MTC 데이터를 캡슐화하여 네트워크에 전송할 수 있다(S10).

단말이 휴지 모드 상태가 아니고(S4), 또한 일정 시점 안에 정상적인 핸드오버(HO: handover)가 발생한다면 (단, 해당 MTC 서버로의 PDN 연결(connectivity) 가 없었던 경우를 가정), 단말은 핸드오버 절차를 이용하여 MTC 데이터를 캡슐화하여 네트워크에 전송할 수 있다(S11). 한편, 단말이 휴지 모드 상태가 아니고(S4), 또한 일정 시점 안에 정상적인 SR이 발생한다면, 단말은 SR 절차를 이용하여 MTC 데이터를 캡슐화하여 네트워크에 전송할 수 있다(S12).이하, 단말이 MTC 데이터를 캡슐화시켜 전송하는 방법을 구체적으로 설명한다: 첫째, 위치 갱신 메시지를 이용하는 실시 예와; 둘째 서비스 요청 메시지를 이용하는 실시 예를 설명한다.

(1) 위치 갱신 메시지(Location Update message) (예를 들어, TAU /RAT 절차)에 MTC 데이터(MTC small user data)를 캡슐화(encapsulation)시켜 전송하는 방법을 개략적으로 설명한다.

위치 갱신 메시지를 이용하여 MTC 데이터를 캡슐화 시켜 전송하는 방법은, MTC 단말이 위치가 고정되지 않고 이동 성향이 강한 단말에 유용할 것이다. 즉, 자주 이동함에 따라, 단말의 위치를 네트워크에 갱신하는 경우에 적합하다. 예를 들어, 사람에게 부착된 건강보조장치(health care device)가 그 예이다.

① 단말은 MTC 데이터(즉, MTC small data)를 캡슐화(encapsulation) 시켜 원래 목적의 TAU/RAU 관련 파라미터와 함께 요청 메시지(TAU/RAU Request message)에 포함시켜 보낸다. 다만, MTC 데이터를 TAU/RAU Request 메시지에 캡슐화시키는 구체적인 방법을 도 6 내지 도 8을 참조하여 아래에서 설명하기로 한다.

② SGSN/MME는 단말로부터 TAU/RAU 요청(Request) 메시지를 받은 후, 수신한 TAU/RAU 요청메시지에 인디케이터(예를 들어, 도 6의 “Protocol discriminator”) 및/또는 특정 데이터 필드(예를 들어, 도 6의 “Protocol configuration options”)가 포함되어 있는지 확인한다. 그리고, SGSN/MME는 가입자 정보를 확인하여 허가된 가입자 인지 또는 허가된 시간인지 등을 확인한 후, 허가된 가입자 및/또는 허가된 시간이라면 해당 메시지로부터 MTC 데이터를 추출한다.

③ SGSN/MME는 상기 추출된 MTC 데이터를 MTC 서버로 포워딩한다. 레거시 시스템(legacy system)의 SMS 솔루션(solution)을 이용하거나 그 외 다른 종래 기술을 이용하여 포워딩한다. 한편, 부가적으로 MTC 서버로 상기 추출된 MTC 데이터 포워딩 전에, 인증 (authentication) 과정 혹은 단말의 조건 및 능력(예를 들어, 단말이 상기 MTC 데이터 전송이 허가된 단말인지, 또는 허가된 시간에 보낸 것인지 등을 확인)등을 확인할 수 있다. 또한, SGSN/MME 혹은 EPC안의 다른 네트워크 노드(예를 들어, SMS 서버)는 MTC 서버로부터 ACK을 받을 때까지 데이터를 유지하고 포워딩(forwarding) 및 재전송(retransmission) 할 수 있는 기능을 가져야 한다.

④ 단말에게 TAU 허용/거절(accept/reject) 메시지를 사용하여, 승인(Acknowledgement)를 전송한다. 여기서, 승인(Acknowledgement)이란 해당 MTC 데이터를 성공적으로 받았다 혹은 MTC 서버로 보내졌다 등을 의미한다. 그리고, TAU 허용/거절(accept/reject) 메시지에 캡슐화되어 전송된 MTC 데이터는, SGSN/MME에서 추출된 후. TAU/RAU 절차 자체의 성공여부와 관계없이 MTC 서버로 포워딩된다. 이하, 표1 및 표2를 참조하여 상기 ACK(acknowledgement)를 보내는 방법을 설명한다. 표 1은 TAU accept 메시지의 컨텐츠이고, 표 2는 부가 갱신 유형의 정보 엘리먼트(additional update type information element)이다. 다만, TAU accept/reject 메시지의 의미와 관계없이 MTC 데이터를 전송하기 위한 ACK/NACK을 보내는 방법을 설명한다:

1) 표 1에 도시된 바와 같이, TAU accept 메시지의 “additional update type” 필드를 이용, MTC 데이터 전송의 ACK/NACK 의미로 확대하여 사용할 수 있다;

2) 도 6의 TAU request 메시지에서와 같이 “Protocol discriminator”에 MTC 데이터 관련 정보를 포함하고 있음을 나타내는 인디케이터를 함께 보낼 수도 있다;

3) 한편, 새로운 필드를 추가하여, MTC 데이터의 전송 여부의 ACK/NACK을 전송할 수도 있다;

4) 새로운 필드를 추가적으로 더 지정하여, ACK/NACK 정보 뿐만 아니라 MTC 서버로부터 전달된 지시사항 혹은 변경된 허가(admission) 정보 등이 캡슐화되어 포함 될 수도 있다.

이하, MTC 데이터를 캡슐화하는 방법을 상세히 설명한다.

도 6는 본 발명의 일 실시 예로서, TAU 요청 메시지에 MTC 데이터를 캡슐화시키는 방법이 적용된 TAU 요청 메시지(TAU request message)의 구성을 나타내는 표이다.

도 7은 ‘Protocol discriminator’ 인디케이터의 값을 도시한 표이다.

도 8은 ‘Protocol configuration options’필드의 information element를 도시한 것이다. 한편, TAU 요청 메시지의 packet field의 상세 내용은 표준문서 TS 24.301, TS 24.007, TS 24.008 등을 원용하기로 한다.

TAU 요청 메시지에 MTC 데이터 캡슐화하는 방법은 일 예로서, 아래와 같이 세가지 실시 예를 들 수 있다. 이하, 도 6 내지 도 8을 참조하여 설명한다:

1. 인디케이터 필드(indicator field)와 컨텐츠 필드(contents field)를 포함하여 TAU 요청 메시지에 캡슐화하는 경우.

- 인디케이터 필드는 MTC 데이터가 포함되어 있음 가리키는 지시자이고 (예를 들어, 도 6에서, “Protocol discriminator”필드는 이에 해당하는 인디케이터), 컨텐츠 필드는 MTC 데이터의 내용 자체가 있는 필드(예를 들어, 도 6에서 “Protocol Configuration Options” 필드)이다.

- 인디케이터는 기존의 TAU request message에 있던 field를 활용할 수 있다. 예를 들어, 기존의 TAU 요청 메시지의 특정 필드를 이용하거나, 또는 도 7에 도시된 바와 같이,“Protocol discriminator”의 차후 사용을 위해 예비로(reserved) 남겨놓았던 값(value)(즉, 도 7에서 “Protocol discriminator”의 값은 ‘1110’)를 사용할 수 있다.

- 실제 MTC 데이터를 포함하기 위해서, 도 6에 도시된 바와 같이 TAU 요청 메시지에 PCO(Protocol Configuration Options)와 같은 필드를 추가해서 사용한다. 한편, POC필드는 TAU 요청 메시지에 새로 정의하여 포함시킨 것이다. 또는 새로운 유형의 필드를 정의하여, MTC 데이터를 그 정의한 필드에 포함시켜 사용할 수도 있다.

2. 인디케이터를 기존의 다른 플랙(flag)틀 통하여 구분할 수도 있다. 예를 들어, 특정 버전 값 이상이면, 이 버전 값을 나타내는 플랙을 통하여, MTC 데이터가 포함되어 있다는 것을 가리키는 인디케이터로 사용할 수도 있다.

3. TAU 요청 메시지에 인디케이터 없이 MTC 데이터의 컨텐츠(contents)만 포함시키는 경우:

예를 들어, TAU 요청 메시지에 PCO 필드가 있다면, MTC 데이터가 있다는 것을 함축적으로 알 수 있다.

한편, 전송할 MTC 데이터(즉, 일명 MTC small data)의 사이즈가 만약 정의된 데이터 길이(data length)보다 큰 경우 발생할 수 있는 상황을 아래와 같은 예시와 같다: 도 8은 PCO의 information element의 테이블이다. 도 8에서 데이터 길이를 나타내는 필드(“Length of protocol ID 1 contents”)가 예시되어 있다. 도 9는 본 발명의 일 실시 예로서, MTC 데이터의 크기가 정의된 기준 길이보다 큰 경우에 처리하는 방법을 도시한 흐름도이다.

- 단말이 네트워크로 업링크 MTC 데이터를 전송할 것이 발생하면, 그에 MTC 데이터를 전송할 절차를 선택한다(S11 및 S12). 이때, 만일 절차 별로 MTC 데이터를 전송할 수 있는 데이터 크기가 다르다면, 해당 절차를 고려하여 결정된다. 예를 들어, PCO 필드의 용량 이상으로 MTC 데이터의 크기가 크다면(S13), MTC 데이터를 분리하여야 할 것이다. 따라서, MTC 데이터가 사이즈 때문에 분리 되었음을 나타내는 인디케이터가 추가적으로 필요할 것이다;

- 또한, MTC 데이터를 분리하였으므로, 그 분리된 MTC 데이터의 일련번호(sequence number)를 나타내는 정보(또는 필드)가 추가로 필요할 수도 있다;

- MTC 데이터가 커서 여러 개로 분리되었다면, 이를 수신한 MME 입장에서는 그러한 indicator를 판단 내지 판독(이해)하고, 그에 상응하는 다음 동작을 결정할 수 있는 기능(function)이 필요할 것이다;

- 그리고, MME는 분리된 MTC 데이터를 수신 및 결합하여 MTC 서버로 전송하거나, 또는 분리된 상태에서 MTC 데이터를 전송할지를 결정할 수 있는 능력이 추가적으로 필요하다;

- 위와 같은 조건들을 추가로 고려하여, MTC 데이터가 분리되었음을 알리는 인디케이터를 포함시키고, 새로운 절차를 선택하여 네트워크로 MTC 데이터를 전송할 것이다(S15 및 S16).

(2) 이하, 본 발명의 일 실시 예인, 서비스 요청 메시지(Service Requested message) (예를 들어, UE triggered Service Request 메시지)에 MTC 데이터(small user data)를 캡슐화 시켜 전송하는 방법을 설명한다.

① 단말은 MTC 데이터를 캡슐화시켜 서비스 요청 메시지(Service Request message)에 포함시켜 보낸다. 한편, 단말이 실제 서비스가 필요해서 요청(request)하는 경우뿐만 아니라, 서비스 요청(service request)과 독립적으로 MTC 데이터를 전송하기 위한 목적으로 요청 메시지를 활용할 수도 있다. MTC 데이터를 서비스 요청 메시지에 캡슐화하는 방법은, 도 6 내지 도 8을 참조하여 설명한 실시 예가 그대로 적용될 수 있으며, 다만, 그 대상 메시지가 TAU 요청 메시지가 아니라 서비스 요청 메시지이다.

② SGSN/MME는 서비스 요청(Service Request) 메시지를 단말로부터 받은 후, 해당 메시지로부터 MTC 데이터를 추출한다. 이때, 도 6 내지 도 8을 참조하여 설명한 바와 같이, 예를 들어, MTC 데이터가 캡슐화된 서비스 요청 메시지에 인디케이터가 있는지를 확인하고, 그 인디케이터가 지시하는 위치에서 MTC 데이터를 추출하게 된다. 만일, 서비스 요청 메시지를 이용하여 MTC 데이터의 전송만을 위해 메시지를 보낸 경우라면, SGSN/MME는 서비스 요청 메시지에 캡슐화된 MTC 데이터를 추출한 후, 해당 서비스 요청 절차(service request procedure)를 중단시킨다. 한편, 부가적으로 상기 MTC 데이터를 추출하기 전에, 인증 (authentication) 과정 혹은 단말의 조건 및 능력(예를 들어, 단말이 상기 MTC 데이터 전송이 허가된 단말인지, 또는 허가된 시간에 보낸 것인지 등을 확인)등을 확인할 수 있다.

③ 그리고, SGSN/MME는 그 추출된 MTC 데이터를 MTC 서버로 포워딩한다.

이때, SGSN/MME는 서비스 요청 절차(Service Request procedure)가 완료 되기 전에, MTC 데이터를 MTC 서버로 포워딩 이 시작될 수 있다. 레거시 시스템(Legacy system)의 SMS 솔루션(solution)을 이용하거나 그 외 다른 종래 기술을 이용하여 포워딩한다. 한편, 부가적으로 MTC 서버로 상기 추출된 MTC 데이터 포워딩 전에, 인증 (authentication) 과정 혹은 단말의 조건 및 능력(예를 들어, 단말이 상기 MTC 데이터 전송이 허가된 단말인지, 또는 허가된 시간에 보낸 것인지 등을 확인)등을 확인할 수 있다. SGSN/MME 혹은 EPC 안의 다른 네트워크 노드는, MTC 서버로부터 ACK을 받을 때까지 MTC 데이터를 유지하고, 또한 포워딩 및 재전송(retransmission) 할 수 있는 기능을 가져야 한다.

④ SGSN/MME는 단말에게 승인(Acknowledgement) 메시지를 전송한다. 여기서, 승인(Acknowledgement)는 해당 MTC 데이터를 성공적으로 받았다거나, 또은 MTC 서버로 보내졌다 것을 의미한다. 그리고, MTC 데이터는 서비스 요청 절차(Service Request procedure) 자체의 성공여부와 관계없이 MTC 서버로 포워딩될 수 있다.

이상과 같이, TAU/RAU 절차의 메시지 및 서비스 요청 메시지(예를 들어, UE triggered service request)에 단말이 MTC 데이터를 캡슐화시켜 네트워크노드(예를 들어, SGSN 또는 MME)에 전송하는 방법을 설명하였다.

이하, 도 10 및 도 11의 신호 흐름도를 통하여, 본 발명에 따른 MTC 데이터를 제어신호에 캡슐화시켜 효율적으로 전송하는 방법을 설명한다.

도 10은 본 발명의 일 실시 예로서, 단말이 TAU 절차를 이용하여 MTC 데이터를 캡슐화하여 네트워크로 전송하는 방법을 도시한 신호 흐름도이다. 다만, 도 10은 본 발명이 위치등록 절차에 적용된 실시 예이다.

이하, 도 10을 참조하여 설명한다.

S101: 단말은 MTC Data 전송하여야 하는 경우, 그 MTC 데이터를 전송할 절차를 결정 내지 선택을 한다.

- 단말(10)은 MTC 데이터(small data)를 MTC 서버(80)로 전송 할 것을 결정한다(S101). 이때, MTC 장치, 즉 단말(10)이 미리 구성(pre-configuration)되어 있는 정보에 따라 자발적으로 MTC 데이터의 전송을 결정할 수 있다. 또는, 단말(10)이 MTC 서버 혹은 다른 네트워크 엔티티(entity)로부터 MTC 데이터를 특정 MTC 서버(80)로 전송 할 것을 요청 받아 MTC 데이터의 전송을 결정할 수도 있다.

- 단말(10)은 어떤 절차(procedure) 중 어떤 메시지를 통하여 MTC 데이터를 전송할지를 결정한다(S102). 도 10은 단말(10)이 위치등록절차(예를 들어, TAU: tracking area update procedure)를 사용하기로 결정한 실시 예에 해당한다. 한편, S102의 결정은 어떤 MTC 서비스인가 혹은 어떤 특성의 device인지 혹은 어떤 가입자 정보를 가졌는가 등에 따라, 사전 구성(pre-configuration)에 의해 혹은 다이나믹하게 결정될 수 있다. 단말(10)은 TAU 절차의 시작을 트리거(trigger)한다. 한편, 단말(10)이 TAU 절차를 트리거하는 조건은 종래기술인 바, 해당 기술에 대한 상세한 설명은 생략한다.

S102: 단말(10)은 상기 S101의 결정한 TAU 절차에서 TAU 트리거(trigger) 수행하고, MTC 데이터를 TAU 요청 메시지(TAU request)에 캡슐화시킨다. 이때, TAU 요청 메시지에 MTC 데이터를 캡슐화시키는 방법 및 메시지의 구성은, 도 6 내지 도 8을 참조하여 설명한 바와 같다.

S103-1 ~ S103-2: 단말(10)은 캡슐화된 MTC 데이터(즉, encapsulated MTC small data)를 포함하는 TAU 요청 메시지를 eNB(20)을 경유하여 MME(30)에 전달한다. 이때, 도 6 내지 도 8에서 설명한 바와 같이, TAU 요청 메시지에는 MTC 데이터가 캡슐화(encapsulation)되어 있는지를 가리키는 인디케이터(또는 파라미터) 및/또는 단말(10)이 MTC 장치인지를 가리키는 인디케이터(또는 파라미터)가 포함되어 있을 수 있다.

S104-1 ~ S104-2: MME(30)는 old MME(31)로부터 단말(10)의 컨텍스트(context)를 받아온다. 이때, 새로운 MME(30)는 단말(10)의 가입자 정보를 컨텍스트 요청/응답 (context request/response) 과정을 통해 획득한다. 또한, 상기 단말의 가입자 정보에는 MTC 관련 가입자 정보도 포함되어 있을 수 있다.

S105: 단말(10)은 필요에 따라 인증(authentication) 및/또는 보안(security) 관련 과정이 수행될 수도 있다.

S106: MME(30)는 상기 TAU 요청 메시지를 수신하고, 그 TAU 요청 메시지가허가된 MTC 장치 및/또는 허가된 사용자로부터 온 것인지 확인한다. 또한, MME(30)는 상기 TAU 요청 메시지에 MTC 데이터가 캡슐화(encapsulation)되어 있는지 등을 확인한다. MTC 데이터가 캡슐화되어 있는지 확인 방법은, 도 6 내지 도 8을 참조하여 설명한 바와 같다. 즉, MME(30)는 상기 TAU 요청 메시지에 포함된 인디케이터를 통해 알 수도 있고, 또는 인디케이터가 포함되어 있지 않은 경우 TAU 요청 메시지 구조의 MTC 데이터가 있는 필드를 확인해보고 알 수도 있다. 한편, 가입자 정보를 통해 MTC 데이터의 캡슐화를 확인 해야 할지 여부를 판단 할 수도 있다. 또한, 이러한, MTC 데이터의 캡슐화를 확인하는 과정은, 기존의 TAU 절차와 병행하거나, 독립적으로 수행될 수도 있다.

이상과 같이, TAU 요청 메시지에 포함된 인디케이터 또는 특정 필드를 확인하여, MME(30)는 TAU 요청 메시지에서 MTC 데이터를 추출한다.

S107: MME(30)는 추출한 MTC 데이터를 MTC 서버(80)로 전송한다. 한편, S107과정은 현 SMS 방식을 이용하거나, 기타 다른 전송 메커니즘을 이용할 수 있다. S107 과정은 기존의 절차(예를 들어, TAU 절차)와 병행하여 수행되거나, 독립적인 시그널링(예를 들어, 별도로 정의된 제어 시그널링)을 통하여 수행될 수도 있다. 한편, MME(30)가 목적지 MTC 서버(80)의 주소를 알 수 있는 방법은, 다음과 같이 여러 옵션(option)이 있을 수 있다: i) MTC 장치, 즉 단말(10)이 MTC 데이터를 보내 올 때, 주소 정보를 함께 캡슐화하여 전송한다; ii) MME(30)에 미리 네트워크 구성(network configuration) 정보로써 저장 되어 있을 수 있다; iii) MME(30)가 가입자 정보를 HSS(70)로부터 가져올 때 MTC 가입자라는 정보와 함께 해당 서비스를 지원하는 MTC 서버(80)의 주소가 포함 되어 질 수 있다.

S108: 이 과정은 종래 기술의 TAU 절차로서, 상기 S106 및 S107과 독립적으로 수행된다.

S109: MME(30)는 상기 TAU 요청 메시지에 대하여, TAU 허락 (TAU accept) 또는 거절 (TAU reject)메시지를 보낸다. MME(30) 단말(10)에게 TAU 허락 또는 거절 메시지를 전송할 때, MTC 데이터를 MTC 서버에 보냈다는 Ack 정보를 TAU 허락 또는 거절 메시지에 포함시켜 보낼 수 있다. TAU 절차의 성공여부와 관계없이, MME(30)는 MTC 서비스를 진행한다. 이 Ack 정보는 인디케이터 형태로 혹은 TAU 허락 또는 거절 메시지에 캡슐화시킨 데이터 형태로 전달될 수 있다. 이 Ack 정보의 의미는 다음 중 하나가 될 수 있다: 1)즉, MME(30)가 단말(10)로부터 캡슐화된 MTC 데이터를 성공적으로 수신하였음; 2) MME(30)가 TAU 요청 메시지에서 MTC 데이터를 추출하여 MTC 서버(80)로 전송하였음; 3) MTC 서버(80)가 MTC 데이터를 성공적으로 수신되었음을 확인; 4) MME(30)가 MTC 데이터 추출 등의 실패로, 단말에게 재전송이 필요함을 요청하는 의미; 5) MTC 서버(80)로부터 전송된 다운링크 데이터(downlink user data)를 캡슐화하여 단말에게 전송할 수도 있다; 6) 기타 보고할 사항 등이 포함될 수도 있다.

S110: MME(30)는 TAU 허용 또는 TAU 거절 메시지를 단말(10)로 보내기 전에 또는 후에, MTC 서버(80)로부터 ack를 받을 수 있다. 따라서, MME(30)는 저장 및 전달 기능(store and forward role)을 가지고 있을 수 있으며, MTC 서버(80)로부터 필요 시 재전송을 수행할 수 있다. 한편, 재전송을 위한 저장 및 전달 기능(store and forward role)은, MME(30)가 아닌 네트워크의 제 3의 노드가 수행할 수도 있다. TAU accept 메시지를 단말로 보낸 이후에 MTC 서버로부터 ACK를 받은 경우, 추가적으로 별도의 메시지를 통해 단말에게 ACK 메시지를 전송 할 수 있다.

이상과 같이, 도 10의 실시 예는, TAU 절차 중의 TAU 요청 메시지를 이용하여 MTC 데이터를 캡슐화하여 보냄으로써, 종래 기술에서 TAU procedure(도3)를 마친 후, MTC 데이터를 전송하려는 시점에서 서비스 요청(service request)과 같은 추가적인 베어러 설정(bearer setup) 과정이 필요하지 않다. 즉, 본 발명의 도 10의 실시 예는 MTC 데이터 전송을 위한 추가적인 절차procedure 없이, TAU 절차만으로 MTC 데이터small data를 전송할 수 있다.

도 11은 본 발명의 일 실시 예로서, 단말이 서비스 요청 절차를 이용하여 MTC 데이터를 캡슐화하여 네트워크로 전송하는 방법을 도시한 신호 흐름도이다. 다만, 도 11은 본 발명이 서비스 요청 메시지(service requested message)(예를 들어, UE triggered service request)에 적용된 실시 예이다.

이하, 도 11을 참조하여 설명한다.

도 11의 S121 ~ S122는 도 10의 S101 ~ S102에 대응된다. 다만, 도 11의 실시 예는 서비스 요청(SR: service request) 메시지를 이용하여 MTC 데이터를 캡슐화하여 전송하는 점이, 도 10의 대응과정과 대비된다.

즉,

S121: 단말은 MTC Data 전송하여야 하는 경우, 그 MTC 데이터를 전송할 절차를 결정 내지 선택을 한다.

- 단말(10)은 MTC 데이터(small data)를 MTC 서버(80)로 전송 할 것을 결정한다(S121). 이때, MTC 장치, 즉 단말(10)이 미리 구성(pre-configuration)되어 있는 정보에 따라 자발적으로 MTC 데이터의 전송을 결정할 수 있다. 또는, 단말(10)이 MTC 서버 혹은 다른 네트워크 엔티티(entity)로부터 MTC 데이터를 특정 MTC 서버(80)로 전송 할 것을 요청 받아 MTC 데이터의 전송을 결정할 수도 있다.

- 단말(10)은 어떤 절차(procedure) 중 어떤 메시지를 통하여 MTC 데이터를 전송할지를 결정한다(S122). 도 11은 단말(10)이 UE triggered service request를 사용하기로 결정한 실시 예에 해당한다. 한편, S122의 결정은 어떤 MTC 서비스인가 혹은 어떤 특성의 장치인지 혹은 어떤 가입자 정보를 가졌는가 등에 따라, 사전 구성(pre-configuration)에 의해 혹은 다이나믹하게 결정될 수 있다. 단말(10)은 서비스 요청(SR: service request)의 절차를 트리거(trigger)한다.

S122: 단말(10)은 상기 S121의 결정한 서비스 요청 트리거(trigger)를 수행하고, MTC 데이터를 서비스 요청 메시지에 캡슐화시킨다.

이때, 서비스 요청 메시지에 MTC 데이터를 캡슐화시키는 방법 및 메시지의 구성은, 도 6 내지 도 8에 도시된 메시지의 구성의 해당 파라미터(또는 인디케이터) 내지 필드(예를 들어, PCO 필드)를, 서비스 요청 메시지에 적용할 수 있다. 한편, 서비스 요청 메시지는 캡슐화시킨 MTC 데이터 만을 MME(30)에 전송하는 용도만으로도 사용될 수 있다.

이하, MTC 데이터를 서비스 요청 메시지에 캡슐화시키는 방법을 상세히 설명한다. 본 발명에서 제시하는 실시 예는: 2개의 인디케이터를 사용하는 방법과; 한 개의 인디케이터를 사용하는 방법과; 인디케이터 없이 MTC 데이터의 컨텐츠만을 서비스 요청 메시지에 포함시키는 방법으로 구분된다. 표 3은 서비스 요청 메시지의 내용을 나타낸 테이블이다. 이하, 표 3를 참조하여, 설명한다.

- 2개의 인디케이터(indicator)를 사용하는 방법을 설명한다:

1. MTC 데이터가 포함되어 있다는 것을 가리키는 인디케이터와;

2. MTC 데이터 만을 위한 요청 메시지라는 것을 가리키는 인디케이터를 사용하는 방법이다.

이때, 위에서 언급한 두 개의 인디케이터는 기존의 서비스 요청 메시지(Service Request message)에 있던 필드를 활용할 수 있다. 즉, 기존의 필드, 예를 들어 “Protocol discriminator”의 필드를 확장해서 사용하거나, 새로운 필드를 추가한다. 한편, 두개의 인디케이터의 값을 다르게 하여 하나의 필드로 나타낼 수도 있고, 별도의 필드로 각각 구성 할 수도 있음;

3. 그리고, MTC데이터의 내용(contents)을 모두 서비스 요청 메시지(Service Request request message)에 포함시킬 수 있다: 실제 데이터를 포함하기 위해서는 PCO 필드를 추가해서 사용한다.

- 1개의 인디케이터를 사용하는 방법을 설명한다:

1. MTC 데이터가 포함되어 있다는 것을 가리키는 인디케이터 또는 MTC 데이터 만을 위한 전용의 요청 메시지(request message)라는 것을 가리키는 인디케이터를 사용한다. 이때, 인디케이터는 기존의 서비스 요청 메시지(Service Request message)에 있던 필드를 활용할 수 있다. 예를 들어, 기존의 field, 즉 “Protocol discriminator”의 차후 확장(future enhancement)를 위해 예비(reserved) 로 남겨놓았던 값(value)를 사용하여, 이 서비스 요청(service request)은 MTC 데이터 만을 전송하기 위해 보내진 메시지 임을 가리키는 인디케이터에 해당한다. 또한, 하나의 인디케이터만을 사용하는 경우는 다른 필드들의 내용을 보고 MTC 데이터가 있는지, 또는 MTC 데이터 만을 위한 요청 메시지인지 등을 함축적으로 판단할 수 있다. 또한 이러한 하나의 인디케이터만을 사용하는 경우, 형식적으로 하나의 필더로 여러 의미를 함께 내포하고 있을 수 있다.

2. 실제 MTC 데이터를 포함하기 위해서는 PCO 필드를 추가해서 사용할 수 있다. 이때, 실제 MTC 데이터를 포함하기 위해서는 PCO 필드를 추가해서 사용한다.

- 인디케이터 없이 MTC 데이터의 내용(contents)만 포함하여 사용하는 방법을 설명한다:

예를 들어, PCO 필드가 있다면, MTC 데이터가 있다는 것을 함축적으로 알 수 있다.

S123-1 ~ S123-2: 캡슐화된 MTC 데이터가 포함된 서비스 요청 메시지가eNodeB(20)을 경유하여 단말(10)에서 MME(30)으로 전송된다. 표 3을 참조하여 설명한 바와 같이, 상기 서비스 요청 메시지에는 MTC 데이터가 캡슐화되어 있는지 여부, 또은 MTC 장치 여부를 확인할 수 있는 파라미터(parameter) 혹은 인디케이터가 포함되어 있을 수 있다.

S124: 한편, 필요에 따라 단말(10)의 인증(authentication), 및/또는 보안(security) 관련 절차가 수행될 수 있다.

S125: MME(30)는 MTC 데이터를 추출한다. 즉, MME(30)는 허가된(인증된) MTC 장치(즉, 단말)로부터 전달된 서비스 요청 메시지인지, 또는 MTC 데이터가 캡슐화(encapsulation)되어 있는지 등을 확인한다. 예를 들어, MME(30)는 표 3과 같은 서비스 요청 메시지의 내용을 확인하여, 인디케이터 및 MTC 데이터에 기초하여 검색하고 그에 따라 캡슐화된 MTC 데이터의 추출과정을 수행한다. 이러한 과정은 기존의 서비스 요청 절차와 병행하여, 또는 독립적으로 수행될 수 있다.

S126: MME(30)는 추출된 MTC 데이터를 MTC 서버(80)로 전송한다:

한편, S126 과정은 SMS 방식을 이용하거나, 기타 다른 전송 메커니즘을 이용할 수 있다. 이때, MME(30)가 목적지 MTC 서버(80)의 주소를 알 수 있는 방법은 다음과 같이 여러 option이 있을 수 있다: 1) MTC 장치(즉, 단말)가 MTC 데이터를 보내 올 때, 주소 정보를 함께 캡슐화하여 전송할 수 있다; 3) MME(30)에 네트워크 구성(network configuration) 정보로써 미리 저장되어 있을 수도 있다; 3) MME(30)가 가입자 정보를 HSS(70)로부터 가져올 때, MTC 가입자라는 정보와 함께 해당 서비스를 지원하는 MTC 서버(80)의 주소가 포함 되어 질 수 있다.

한편, S125 및 S126와 별도로, MME(30)는 서비스 요청 절차(service request procedure)를 중단시킬 수 있다. 보다 상세히 설명하면 다음과 같다:

- 즉, eNB(20)로 S1 해제 명령(release command)를 전송한다. 기존의 서비스 요청 절차를 그대로 수행하게 되면, 단말(10)과 코어 망(core network) (S/P-GW) 사이에 베어러(bearer)가 설정(setup)된다. 그러나, 이렇게 서비스 요청 절차를 중단시킴으로써, 베어러 설정(bearer setup) 없이 MTC 서비스를 위한 MTC 데이터를 전송시킬 수 있다;

- 또는, MTC 데이터를 전송할 목적으로 시작된 절차가 아니라, 다른 용도의 서비스 요청 (Service Request)를 포함하고 있었다면, 종래기술의 서비스 요청 절차가 상기 S125 및 S126과 독립적으로 수행될 수 있다.

- S1 해제 명령(release command) 전송 시, 혹은 서비스 요청 절차(Service Request procedure)가 계속 진행된 경우, 서비스 요청 허락/거절 메시지(Service Request accept/reject message)를 전송할 때, 다음과 같은 Ack 정보 중 하나 이상을 포함하여 전송할 수 있다. 즉, 서비스 요청 절차(Service Request procedure)의 성공여부와 관계없이 MTC 서비스를 진행한다. 이 정보들은 인디케이터 형태로, 또는 MTC 데이터를 캡슐화하는 형태로 전달될 수 있다: 즉, 이 정보들의 예는, i) 단말(10)로부터 캡슐화 된 MTC 데이터를 성공적으로 받았음을 나타내는 정보; ii) 추출된 MTC 데이터를 MTC 서버로 전송하였음을 나타내는 정보; iii) MTC 서버(80)가 MTC 데이터를 성공적으로 수신하였음을 확인할 수 있는 정보; iv) MTC 데이터의 추출 등의 실패로 인하여, 단말이 MTC 데이터의 재전송이 필요함을 요청하는 정보; v) MTC 서버로부터 전송된 다운링크 사용자 데이터(downlink user data)를 나타내는 정보; vi) 기타 report 할 사항 등을 나타내는 정보등이다.

S128: eNB(20)는 단말(10)로 RRC connection release를 요청한다.

- MME(30)의 서비스 요청 절차(Service request procedure) 중단의 후속조치로써, S1 해제 명령(release command)를 받은eNB(20)는 무선구간의 연결을 해제(release) 시킨다.

- S1 해제 명령(release command)에 포함되어 있는 ACK 정보를 단말(10)로 포워딩(forwarding) 시킬 수 있다.

S129: MME(30)는 단말(10)로 S1 release command/RRC connection release를 보내기 전 또는 후에, MTC 서버(80)로부터 ack를 받을 수 있다. 따라서, 저장 및 포워딩 기능(store and forward role)을 가지고 있을 수 있으며, 필요 시 MTC 서버(80)로 재전송을 수행한다. 한편, 재전송을 위한 저장 및 포워딩 기능 (store and forward role)은 MME(30)가 아닌 네트워크의 제 3의 노드에서 가지고 있을 수도 있다. S128이후에 즉, RRC 해지 메시지를 단말로 보낸 이후에 MTC 서버로부터 ACK를 받은 경우, 추가적으로 별도의 메시지를 통해 단말에게 ACK 메시지를 전송 할 수 있다.

이상과 같이, 도 11의 실시 예는, 종래 서비스 요청 절차(예를 들어, UE triggered Service Request procedure)와 비교하여 볼 때, 도 4와 같이 모든 과정을 수행하지 않고, 특정 제어 시그널링 메시지(예를 들어, service request message)를 통하여 MTC 데이터를 전송할 수 있다.

이상, 상술한 본 발명의 실시 예들은, 단말이 온라인(online) 상태에서 MTC 데이터를 전송하는 과정을 중심으로 기술되어 있으나, 본 발명이 제안하는 MTC 데이터 캡슐화(user data encapsulation)의 개념은 오프라인의 MTC 데이터 전송(offline small data transmission)으로 확장 적용할 수 있다. 즉, 오프라인(offline) 상태였던 단말이, 예를 들어 어태취(attach) 과정을 수행하는 동안, 또는 그 이후에 MTC 데이터를 캡슐화하는 방법을 적용하여 네트워크로 전송할 수 있다. 여기서, 온라인과 오프라인의 차이는 MTC 통신이 시작되기 전 단말의 상태를 나타낼 뿐이며, 같은 개념의 절차가 적용될 수 있다. 다만, 온라인의 경우 위치 갱신(location update) 시 및 서비스 요청(service request) 시 MTC 데이터를 캡슐화하여 전송하는 방법을 사용할 수 있으나, 오프라인의 경우 어태취/연결(attach/connection)된 후, 최초 위칭 등록(location update) 시 또는 서비스 요청 (service request)시 사용할 수 있다.

한편, 본 발명은 E-UTRAN/EPS를 기준으로 실시 예를 보여주고 있으나, 기존 3GPP 시스템(legacy 3GPP system)에서도 동일 목적의 해당 절차에 적용시킬 수도 있다. 또한, 본 발명의 실시 예들은 MTC 장치에서 MTC 서버로 상향링크 데이터(uplink data) 전송을 중심으로 실시 예를 보여주고 있으나, MTC 서버로부터 MTC 장치로의 하향링크 데이터(downlink data) 전송에서도 적절한 message안에 data를 encapsulation 시킬 수 있다: 즉, 본 발명에서 설명한

(1) Location Update message (예를 들어, TAU /RAT procedure, 등)에 MTC 데이터(MTC small user data)를 캡슐화시켜 전송하는 방법과;

(2) Service Requested message (예를 들어, UE triggered Service Request.)에 MTC 데이터(MTC small user data) 를 캡슐화시켜 전송하는 방법과;

(3) 그 외의 절차 상 (예를 들어, attach, paging, handover, NW triggered Service Request procedure, 등)에 제어 시그널링(control signaling)을 전송하기 위한 용도의 메시지 (예를 들어, attach request message, paging message, handover request message, the corresponding accept or reject message, 등) 에 MTC 데이터(MTC small user data) 를 캡슐화시켜 전송하는 방법으로 확장시킬 수 있다.

한편, 여기까지 설명된 본 발명에 따른 방법은 소프트웨어, 하드웨어, 또는 이들의 조합으로 구현될 수 있다. 예를 들어, 본 발명에 따른 방법은 저장 매체(예를 들어, 이동 단말기 내부 메모리, 플래쉬 메모리, 하드 디스크, 기타 등등)에 저장될 수 있고, 프로세서(예를 들어, 이동 단말기 내부 마이크로 프로세서)에 의해서 실행될 수 있는 소프트웨어 프로그램 내에 코드들 또는 명령어들로 구현될 수 있다.

이상, 본 발명은 도면에 도시된 실시 예를 참고로 설명되었으나, 이는 예시적인 것에 불과하며, 본 발명 기술 분야의 통상의 지식을 가진 자라면 이로부터 다양한 변형 및 균등한 타 실시 예가 가능하다는 점을 이해할 것이다. 따라서, 본 발명의 진정한 기술적 보호 범위는 첨부된 특허청구범위의 기술적 사상에 의해 정해져야 할 것이다.

Claims

(A) MTC(machine type communication) 데이터가 캡슐화되어 있는 제어 시그널링 메시지를 단말로부터 수신하는 단계와;
(B) 상기 제어 시그널링 메시지에서 상기 MTC 데이터를 추출하는 단계와;
(C) 상기 추출한 MTC 데이터를 MTC 서버로 전송하는 단계를 포함하며,
상기 제어 시그널링 메시지는 상기 MTC 데이터가 캡슐화되어 포함되어 있음을 가리키는 인디케이터 필드 및 MTC 데이터의 컨텐츠 필드 중 적어도 하나를 포함하는 이동통신시스템에서의 데이터 전송 방법.
제1항에 있어서, 상기 (B) 단계는
상기 수신한 제어 시그널링 메시지에 캡슐화된 MTC 데이터가 있는지 판단하는 단계를 더 포함하는 것을 특징으로 하는 이동통신시스템에서의 데이터 전송 방법.
제2항에 있어서, 상기 (B) 단계에서
상기 수신한 제어 시그널링 메시지에 상기 인디케이터가 있는지 확인하여, 상기 캡슐화된 MTC 데이터가 있는 것으로 판단하는 것을 특징으로 하는 이동통신시스템에서의 데이터 전송 방법.
제2항에 있어서, 상기 (B) 단계에서
상기 수신한 제어 시그널링 메시지에 상기 MTC 데이터의 컨텐츠 필드가 있는지 확인하여, 상기 캡슐화된 MTC 데이터가 있는 것으로 판단하는 것을 특징으로 하는 이동통신시스템에서의 데이터 전송 방법.
제2항에 있어서, 상기 (B) 단계에서
상기 인디케이터 필드와, 상기 MTC 데이터의 컨텐츠 필드 모두가 상기 수신한 제어 시그널링 메시지에 존재하는 경우, 상기 캡슐화된 MTC 데이터가 있는 것으로 판단하는 것을 특징으로 하는 이동통신시스템에서의 데이터 전송 방법.
제5항에 있어서, 상기 인디케이터 필드는 ‘protocol discriminator’이고,
상기 MTC 데이터의 컨텐츠 필드는 ‘protocol configuration options’인 것을 특징으로 하는 이동통신시스템에서의 데이터 전송 방법.
제1항에 있어서, 상기 (C) 단계는
데이터 전송 방법의 기존 절차와 병행하여 수행되거나, 또는
독립적인 시그널링을 통하여 수행되는 것을 특징으로 하는 이동통신시스템에서의 데이터 전송 방법.
제1항에 있어서, 상기 제어 시그널링 메시지는 제어 평면(control plane) 상의 메시지이고,
상기 제어 시그널링 메시지는 상기 단말이 네트워크에 어태취하는 절차 상의 메시지, 페이징 응답 메시지, 위치 등록 메시지, 또는 트리거 서비스 절차(triggered service procedure) 상의 메시지 중 하나인 것을 특징으로 하는 이동통신시스템에서의 데이터 전송 방법.
삭제
제1항에 있어서,
상기 제어 시그널링 메시지에 대한 허용 또는 거절 메시지를 상기 단말에게 전달할 때, 상기 MTC 데이터에 대한 Ack 정보를 포함하여 전달하는 단계;를 더 포함하는 것을 특징으로 하는 이동통신시스템에서의 데이터 전송 방법.
제1항에 있어서, 상기 MTC 데이터에 대한 Ack 정보는
상기 단말로부터 상기 캡슐화된 MTC 데이터를 성공적으로 수신하였음;
상기 MTC 데이터를 추출하여 상기 MTC 서버로 전송하였음;
상기 MTC 서버가 상기 추출한 MTC 데이터를 성공적으로 수신되었음을 확인;
상기 MTC 데이터 추출 등의 실패로, 상기 단말에게 재전송이 필요함을 요청하는 의미;
상기 단말에게 보고할 사항;
중 적어도 하나를 포함하는 것을 특징으로 하는 이동통신시스템에서의 데이터 전송 방법.
제1항에 있어서,
상기 MTC 서버로 전송한 상기 추출한 MTC 데이터에 대한 응답을 상기 MTC 서버로부터 수신하는 단계를 더 포함하는 것을 특징으로 하는 이동통신시스템에서의 데이터 전송 방법.
(a) MTC(machine type communication) 데이터가 캡슐화되어 있는 서비스 요청 메시지(service request message)를 단말로부터 수신하는 단계와;
(b) 상기 서비스 요청 메시지가 상기 캡슐화 MTC 데이터 만을 전송하는 메시지인지를 판단하는 단계와;
(c) 상기 서비스 요청 메시지에서 상기 MTC 데이터를 추출하는 단계와;
(d) 상기 추출한 MTC 데이터를 MTC 서버로 전송하는 단계를 포함하는 것을 특징으로 하는 이동통신시스템에서의 데이터 전송 방법.
제13항에 있어서, 상기 (b) 단계에서
상기 서비스 요청 메시지가 상기 캡슐화 MTC 데이터 만을 전송하는 용도의 메시지로 판단되는 경우,
상기 단말에 서비스하고 있는 기지국에 서비스 해제 명령을 전송하여, 상기 단말과 상기 기지국 간에 RRC 연결을 해제시키는 단계를 포함하는 것을 특징으로 하는 이동통신시스템에서의 데이터 전송 방법.
제13항에 있어서, 상기 (b) 단계의 판단은
상기 서비스 요청 메시지가 상기 캡슐화 MTC 데이터 만을 전송하는 용도의 메시지인 것을 가리키는 인디케이터가 있는지 확인하여,
상기 서비스 요청 메시지가 상기 캡슐화 MTC 데이터 만을 전송하는 전용메시지로 판단하는 것을 특징으로 하는 이동통신시스템에서의 데이터 전송 방법.
제13항에 있어서, 상기 서비스 요청 메시지는
상기 MTC 데이터가 캡슐화되어 있음을 가리키는 인디케이터 필드와,
상기 서비스 요청 메시지가 상기 캡슐화 MTC 데이터 만을 전송하는 용도의 메시지인 것을 가리키는 인디케이터 필드 중 적어도 하나를 포함하는 것을 특징으로 하는 이동통신시스템에서의 데이터 전송 방법.
제13항에 있어서, 상기 서비스 요청 메시지는
상기 MTC 데이터가 캡슐화되어 포함되어 있음을 가리키는 인디케이터 필드와, 상기 MTC 데이터의 컨텐츠 필드 중 적어도 하나 또는 모두를 포함하는 것을 특징으로 하는 이동통신시스템에서의 데이터 전송 방법.
제13항에 있어서, 상기 서비스 요청 메시지는
상기 MTC 데이터가 존재하고 있음을 함축적으로 가리키는 상기 MTC 데이터의 컨텐츠 필드 만을 포함하는 것을 특징으로 하는 이동통신시스템에서의 데이터 전송 방법.
제13항에 있어서,
상기 MTC 서버로 전송한 상기 추출한 MTC 데이터에 대한 응답을 상기 MTC 서버로부터 수신하는 단계를 더 포함하는 것을 특징으로 하는 이동통신시스템에서의 데이터 전송 방법.