許 陽(yáng)，符 剛

（中國(guó)聯(lián)通網(wǎng)絡(luò)技術(shù)研究院 北京100048）

1 背景

物聯(lián)網(wǎng)給人們?nèi)粘Ｉ顜?lái)很大便利的同時(shí)，也對(duì)運(yùn)營(yíng)商的網(wǎng)絡(luò)產(chǎn)生了巨大的沖擊和挑戰(zhàn)。數(shù)量相當(dāng)可觀(guān)的物聯(lián)網(wǎng)終端將會(huì)周期性地發(fā)送小數(shù)據(jù)分組以傳遞更新的消息，小數(shù)據(jù)分組的容量雖然不大，但是為了發(fā)送小數(shù)據(jù)分組的正常流程需要產(chǎn)生的信令消息數(shù)量驚人，其控制面信令消息的開(kāi)銷(xiāo)遠(yuǎn)大于數(shù)據(jù)面?zhèn)魉托?shù)據(jù)分組的開(kāi)銷(xiāo)。因此，尋找一種能夠有效傳遞小數(shù)據(jù)分組并且將運(yùn)營(yíng)商網(wǎng)絡(luò)沖擊最小化的方案是十分必要的。目前，國(guó)際標(biāo)準(zhǔn)化組織第三代合作伙伴（3GPP）在無(wú)線(xiàn)與核心網(wǎng)2個(gè)工作組中均投入了大量的精力來(lái)研究物聯(lián)網(wǎng)小數(shù)據(jù)分組傳遞的有效解決方案，以下將基于此研究結(jié)果對(duì)控制面和用戶(hù)面的小數(shù)據(jù)分組傳遞方案進(jìn)行介紹，并對(duì)比不同方案的優(yōu)劣點(diǎn)，最后，結(jié)合運(yùn)營(yíng)商已有網(wǎng)元的部署，評(píng)估小數(shù)據(jù)分組傳遞方案對(duì)現(xiàn)有網(wǎng)元的影響。同時(shí)，智能手機(jī)上各應(yīng)用為了保持“永久在線(xiàn)”而產(chǎn)生的心跳消息也可以看作是一種小數(shù)據(jù)，本文介紹的小數(shù)據(jù)分組傳遞方案也可以用于應(yīng)對(duì)智能手機(jī)OTT 業(yè)務(wù)給網(wǎng)絡(luò)帶來(lái)信令風(fēng)暴的威脅。M2M 通信下的小數(shù)據(jù)可能造成的對(duì)網(wǎng)絡(luò)的沖擊是運(yùn)營(yíng)商必須面對(duì)的問(wèn)題。

2 支持M2M 通信的移動(dòng)網(wǎng)絡(luò)架構(gòu)

承載M2M 通信的移動(dòng)網(wǎng)絡(luò)架構(gòu)如圖1 所示，該承載網(wǎng)絡(luò)包括GPRS、EPC（演進(jìn)的分組核心網(wǎng)）、短消息以及IMS（IP 多媒體系統(tǒng)）網(wǎng)絡(luò)。

為了實(shí)現(xiàn)機(jī)器類(lèi)通信（machine type communication，MTC） 功能，網(wǎng)絡(luò)中新增了MTC-IWF（MTC-interworking function，機(jī)器類(lèi)通信—互通功能）網(wǎng)元，用來(lái)隱藏PLMN（公共陸地移動(dòng)網(wǎng)絡(luò)）網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)的功能，如圖1 所示，所有應(yīng)用的小數(shù)據(jù)傳輸都只需要與MTC-IWF 進(jìn)行交互，而不需要考慮核心網(wǎng)拓?fù)浣Y(jié)構(gòu)的影響。圖中的MTC Server 是一個(gè)可選網(wǎng)元，它定義在非3GPP的范圍，同時(shí)又是運(yùn)營(yíng)商控制內(nèi)的設(shè)備，該設(shè)備可以建立一系列的開(kāi)放能力供應(yīng)用服務(wù)器調(diào)用，而不需要為每一個(gè)應(yīng)用都建立單獨(dú)的能力。MTC Server 和MTC-IWF 之 間 由MTCsp 接 口 連接，在使用MTCsp 接口觸發(fā)PLMN 特定功能實(shí)體時(shí)，MTC-IWF 又具有信令中繼或者信令轉(zhuǎn)換的功能。MTC-IWF 是一個(gè)邏輯功能，實(shí)際部署時(shí)可以單獨(dú)設(shè)置網(wǎng)絡(luò)實(shí)體，也可以將該功能集成在其他網(wǎng)絡(luò)實(shí)體中。一個(gè)PLMN 中可以部署多個(gè)MTC-IWF。此外，原有網(wǎng)絡(luò)中的部分實(shí)體也需要進(jìn)行增強(qiáng)來(lái)支持MTC 功能。涉及的網(wǎng)絡(luò)實(shí)體包括HSS/HLR、GGSN/P-GW、MSC/SGSN/MME 等。

圖1 支持M2M 通信的移動(dòng)網(wǎng)絡(luò)架構(gòu)

根據(jù)應(yīng)用服務(wù)器接入方式的不同，可以將網(wǎng)絡(luò)的通信模式分為直接通信模式和間接通信模式。直接通信模式是指MTC 應(yīng)用服務(wù)器直接與網(wǎng)絡(luò)實(shí)體（如GGSN/S-GW+P-GW）進(jìn)行連接，從而實(shí)現(xiàn)與物聯(lián)網(wǎng)終端的通信；間接通信模式是指應(yīng)用服務(wù)器通過(guò)API 與MTC 服務(wù)器相連，通過(guò)MTC 服務(wù)器與移動(dòng)承載網(wǎng)絡(luò)進(jìn)行通信。此外，也可以同時(shí)使用直接通信模式和間接通信模式來(lái)進(jìn)行物聯(lián)網(wǎng)數(shù)據(jù)的傳輸。

3 在保持IDLE 態(tài)的情況下M2M 終端傳遞小數(shù)據(jù)分組的解決方案

根據(jù)3GPP 組織的規(guī)定，LTE/EPC 架構(gòu)下的UE在附著狀態(tài)下分為IDLE 狀態(tài)和Connected 狀態(tài)。IDLE 狀態(tài)時(shí)，空口的RRC 連接處于釋放狀態(tài)，UE 連接的相關(guān)信息僅核心網(wǎng)側(cè)保留，無(wú)線(xiàn)側(cè)的資源則處于釋放狀態(tài)，此時(shí)UE 不能夠通過(guò)用戶(hù)面?zhèn)鬏敂?shù)據(jù)，只有發(fā)起Service Request 流程轉(zhuǎn)變到Connected 狀態(tài)后，UE 才能夠通過(guò)用戶(hù)面?zhèn)鬏敂?shù)據(jù)。

M2M 終端在IDLE 狀態(tài)時(shí)，經(jīng)常只傳遞幾個(gè)小數(shù)據(jù)分組，卻需要觸發(fā)完整的Service Request 流程，造成信令負(fù)荷的加重以及網(wǎng)絡(luò)資源的浪費(fèi)。在IDLE 態(tài)下UE 有效地傳輸小數(shù)據(jù)的前提下，盡量少地產(chǎn)生信令數(shù)量，甚至在不進(jìn)入連接態(tài)的情況下就可以發(fā)送小數(shù)據(jù)，是物聯(lián)網(wǎng)通信需要解決的重要問(wèn)題。目前，該問(wèn)題的解決方案主要分2 類(lèi)：信令面方案和用戶(hù)面方案。

信令面方案是讓IDLE 態(tài)下的UE 通過(guò)信令面直接將小數(shù)據(jù)發(fā)送至網(wǎng)絡(luò)側(cè)，而不需要發(fā)起完整的Service Request 流程進(jìn)入Connected 狀態(tài)，該方案有效地節(jié)省了建立用戶(hù)面連接需要的信令開(kāi)銷(xiāo)，并且實(shí)現(xiàn)的關(guān)鍵功能大多已經(jīng)可以被網(wǎng)元支持；另一類(lèi)小數(shù)據(jù)傳輸方案是用戶(hù)面方案，該方案在最初UE 附著的過(guò)程中為小數(shù)據(jù)傳輸指定了專(zhuān)有連接，此后每當(dāng)IDLE 態(tài)的UE 希望傳送小數(shù)據(jù)時(shí)，不需要信令面的參與就可以直接將數(shù)據(jù)通過(guò)專(zhuān)有連接進(jìn)行傳輸，節(jié)省了信令面的開(kāi)銷(xiāo)。下面對(duì)2 類(lèi)方案進(jìn)行詳細(xì)介紹。

3.1 控制面方案

通過(guò)NAS 信令對(duì)攜帶的小數(shù)據(jù)進(jìn)行傳輸，避免完整的Service Request 過(guò)程，減少信令開(kāi)支。正常的Service Request 流程都需要在最初進(jìn)行NAS 消息交互，用于鑒權(quán)、能力協(xié)商等目的?？刂泼娣桨赋浞掷昧薎DLE 態(tài)下所有UE 進(jìn)入連接態(tài)時(shí)都需要首先與MME 進(jìn)行NAS 消息交換，以進(jìn)行進(jìn)入連接態(tài)的授權(quán)、安全參數(shù)獲取、無(wú)線(xiàn)承載信息等，可以避免建立用戶(hù)面的工作，這樣一來(lái)，在很大程度上就節(jié)省了傳遞小數(shù)據(jù)需要的信令數(shù)量。由于需要傳遞小數(shù)據(jù)，NAS消息的長(zhǎng)度會(huì)增加。如果希望更好地削減信令開(kāi)銷(xiāo)，必要時(shí)可以考慮重用NAS 消息的加密密鑰，但是重用條件和次數(shù)需要規(guī)定，不能無(wú)限地重用，否則，一般條件下，每次NAS 消息的密鑰都需要正常更換。

控制面的方案比較適合于非頻繁的小數(shù)據(jù)發(fā)送。對(duì)于頻繁的小數(shù)據(jù)傳輸或小數(shù)據(jù)與普通數(shù)據(jù)同時(shí)傳送的場(chǎng)景，發(fā)起正常的Service Request 流程更為合適，可以長(zhǎng)時(shí)間保持用戶(hù)面連接以應(yīng)對(duì)頻繁小數(shù)據(jù)的傳輸。

各控制面方案在空口的傳遞辦法都是將小數(shù)據(jù)分組分裝在NAS 消息中，利用NAS 加密功能從UE傳 輸 給MSC/SGSN/MME 后，MSC/SGSN/MME會(huì)進(jìn)行拆封和重封裝功能，并將重封裝后的小數(shù)據(jù)分組轉(zhuǎn)發(fā)至后面的網(wǎng)元。它們之間的主要區(qū)別在于后續(xù)網(wǎng)元的傳遞方法不同，如圖2 所示。

方案一：MSC/SGSN/MME 將小數(shù)據(jù)封裝成GTP-U協(xié)議數(shù)據(jù)分組，通過(guò)核心網(wǎng)元GGSN/S-GW+P-GW 直接傳給應(yīng)用服務(wù)器（Direct 方式）或經(jīng)由MTC 服務(wù)器間接傳給應(yīng)用服務(wù)器（Indirect 方式）。該方案只需要對(duì)現(xiàn)有網(wǎng)元功能進(jìn)行升級(jí)，但該方案沒(méi)有新網(wǎng)元MTC-IWF的參與，不利于對(duì)物聯(lián)網(wǎng)數(shù)據(jù)發(fā)送和接收進(jìn)行統(tǒng)一管理。

方案二：MSC/SGSN/MME 利用傳統(tǒng)的短信中心通過(guò)T4 接口將小數(shù)據(jù)分組傳給MTC-IWF，再由MTC-IWF 傳遞給MTC 服務(wù)器（Direct 方式）。T4 接口方案使用短消息機(jī)制進(jìn)行小數(shù)據(jù)的傳送，支持不攜帶MSISDN的MT 模式小數(shù)據(jù)傳輸，eNode B 和MME 具備傳送短消息的能力，對(duì)于MTC-IWF，需要支持協(xié)議轉(zhuǎn)換功能。

方案三：MSC/SGSN/MME 通過(guò)新增加的T5 接口直接傳給MTC-IWF，再由MTC-IWF 傳遞給MTC 服務(wù)器（Direct 方式）。通過(guò)T5 接口傳送小數(shù)據(jù)的方案可以支持不攜帶MSISDN 進(jìn)行MO 和MT 模式的小數(shù)據(jù)傳輸，需要支持T5 接口及相關(guān)協(xié)議，并需要部署MTC-IWF，執(zhí)行小數(shù)據(jù)的存儲(chǔ)、轉(zhuǎn)發(fā)及擁塞控制功能。

控制面3 種方案的具體描述和對(duì)比見(jiàn)表2 所列，對(duì)于長(zhǎng)遠(yuǎn)考慮來(lái)講，方案二是較好的選擇，而從近期節(jié)省成本的角度考慮，方案一和方案三是不錯(cuò)的選擇。

3.2 用戶(hù)面方案

用戶(hù)面方案大致的思想就是要在成功傳遞小數(shù)據(jù)的前提下，盡量減小空閑態(tài)與連接態(tài)切換產(chǎn)生的信令數(shù)量。用戶(hù)面方案中，在附著的時(shí)候就為小數(shù)據(jù)傳輸建立專(zhuān)用連接，UE 傳小數(shù)據(jù)時(shí)，將該小數(shù)據(jù)和指定的連接ID 送到eNode B，通過(guò)小數(shù)據(jù)傳輸專(zhuān)用的連接進(jìn)行傳輸，這樣的傳輸方式可以避免NAS 消息交互、MME 分配資源等造成的信令開(kāi)支，從而高效地傳送小數(shù)據(jù)。

圖2 控制面方案

表2 控制面方案的比較

在用戶(hù)面方案中，S-GW 中專(zhuān)用連接的端點(diǎn)信息將提供給UE，UE 傳遞上行小數(shù)據(jù)時(shí)，將專(zhuān)用連接的端點(diǎn)信息作為附加信息與小數(shù)據(jù)分組一并傳遞給eNode B，eNode B 使用此附加信息產(chǎn)生GTP-U 數(shù)據(jù)分組，將小數(shù)據(jù)通過(guò)該數(shù)據(jù)分組由S1-U 接口傳遞給S-GW，再由S-GW 執(zhí)行正常的數(shù)據(jù)轉(zhuǎn)發(fā)操作，最終由PGW 路由出去；對(duì)于下行小數(shù)據(jù)，eNode B 在向S-GW發(fā)送GTP-U 數(shù)據(jù)分組時(shí)，會(huì)將下行的TEID 帶給S-GW，S-GW 存儲(chǔ)并按照此TEID 發(fā)送下行數(shù)據(jù)至指定的eNode B。目前，用戶(hù)面解決方案的空口小數(shù)據(jù)傳輸機(jī)制仍沒(méi)有明確的結(jié)論。

如圖3 所示，用戶(hù)面方案中，RAN 側(cè)負(fù)責(zé)分配服務(wù)于小數(shù)據(jù)傳輸?shù)臒o(wú)線(xiàn)資源，而不需要與核心網(wǎng)側(cè)交互來(lái)授權(quán)無(wú)線(xiàn)資源的分配。由于避免了信令面上的交互，用戶(hù)面方案把安全和其他控制相關(guān)的處理功能全都放在了S-GW 上，并且UE 在進(jìn)入其他制式網(wǎng)絡(luò)時(shí)不需要進(jìn)行切換過(guò)程，有效時(shí)間內(nèi)可以憑借最初分配的專(zhuān)用于小數(shù)據(jù)傳輸?shù)腎D 隨時(shí)傳輸小數(shù)據(jù)。

用戶(hù)面實(shí)現(xiàn)小數(shù)據(jù)傳輸有2個(gè)解決方案。

方案一：顆粒度為承載級(jí)別，在用戶(hù)面通過(guò)特定的承載進(jìn)行小數(shù)據(jù)分組的傳輸，該方案的安全過(guò)程只在UE 和S-GW 之間進(jìn)行，此外上行S-GW TEID 可由承載ID 派生出來(lái)。

方案二：顆粒度為PDN 連接級(jí)別，PDN 連接要么是普通PDN 連接，要么是支持小數(shù)據(jù)分組專(zhuān)用的PDN 連接，支持小數(shù)據(jù)分組專(zhuān)用的PDN 連接不能夠建立專(zhuān)有承載，該方案的安全過(guò)程只在UE 和S-GW之間進(jìn)行，上行S-GW TEID 和地址由PDN 連接的ID派生得到。

用戶(hù)面的2個(gè)方案均不需要增加新的網(wǎng)元，只需要對(duì)現(xiàn)有網(wǎng)元進(jìn)行升級(jí)，因此造價(jià)較小，但不容易對(duì)小數(shù)據(jù)分組的接收進(jìn)行統(tǒng)一管理，還會(huì)增加用戶(hù)面負(fù)荷。此外，由于用戶(hù)面的小數(shù)據(jù)分組傳遞過(guò)程不涉及MME的控制，因此，用戶(hù)的位置信息在MME 將不會(huì)得到實(shí)時(shí)更新，容易使MME 認(rèn)為該用戶(hù)不可達(dá)。2 種用戶(hù)面方案的描述和對(duì)比見(jiàn)表3 所列。

4 2類(lèi)小數(shù)據(jù)傳輸方案的比較及其對(duì)網(wǎng)元影響的評(píng)估

根據(jù)前面對(duì)控制面和用戶(hù)面各種方案的描述，概括性地歸納了對(duì)終端、無(wú)線(xiàn)以及核心網(wǎng)網(wǎng)元可能的影響，見(jiàn)表4 所列。M2M 通信模式下的小數(shù)據(jù)分組傳輸方案不可避免地會(huì)對(duì)現(xiàn)有網(wǎng)元造成影響，更有可能增加新的網(wǎng)元和功能，運(yùn)營(yíng)商應(yīng)當(dāng)根據(jù)自身網(wǎng)絡(luò)特點(diǎn)、發(fā)展策略等方面綜合考慮，制定出適合自身的小數(shù)據(jù)傳輸方案。

圖3 用戶(hù)面方案

表3 用戶(hù)面方案比較

表4 控制面和用戶(hù)面方案對(duì)網(wǎng)元可能造成的影響

5 結(jié)束語(yǔ)

物聯(lián)網(wǎng)通信是不可逆轉(zhuǎn)的發(fā)展趨勢(shì)，對(duì)于運(yùn)營(yíng)商來(lái)說(shuō)更是機(jī)遇與挑戰(zhàn)并存。本文對(duì)M2M 通信模式的整體架構(gòu)以及小數(shù)據(jù)傳輸方案進(jìn)行了研究，并對(duì)網(wǎng)元可能造成的影響進(jìn)行了評(píng)估，得出要合理利用現(xiàn)有網(wǎng)絡(luò)的結(jié)論。在保證M2M 通信的前提下，盡量減少成本是運(yùn)營(yíng)商在物聯(lián)網(wǎng)大趨勢(shì)下實(shí)現(xiàn)盈利的一個(gè)關(guān)鍵因素。

1 3GPP TS 23.682 Architecture enhancements to facilitate communications with packet data networks and applications.http://www.3gpp.org/ftp/specs/html-INFO/23682.htm，2013

2 3GPP TR 23.887 Architectural Enhancements for Machine Type and other mobile data applications Communications.http://www.3gpp.org/ftp/specs/html-INFO/23887.htm，2013

3 3GPP TR 23.888 System improvements for Machine-Type Communications (MTC).http://www.3gpp.org/ftp/specs/html-INFO/23888.htm，2013