不同的 machine 類型流量在 MTC Application 與 3GPP 網路之間，可預見有幾種不 同模型的存在。在一種叫做 Direct Model 之下，MTC Application 可以透過 3GPP 網路直 接的與 UE 來進行溝通，如下圖(A)所示。在互補方式下，可預見 Indirect Model 有幾個 子模型，在那些子模型中，MTC Application 主要都是使用 3GPP 網路提供的一些額外服 務來與 UE 之間做溝通。如下圖(B)所示，MTC Application 使用 MTC Server，而 MTC Server 主要是由第三方供應商來提供一些額外價值與加值服務。
也就是說，MTC Server 是不屬於 3GPP 負責，而 MTC Server 與 MTC Application 之間的介面也非 3GPP 所提供，但在 MTC Server 與 3GPP 網路之間的溝通介面是 3GPP 所制定的。如下圖(C)所示，MTC Application 同樣使用 MTC Server，但是其額外價值與 加值服務是由 3GPP 所制訂與提供，MTC Server 與 MTC Application 之間的溝通介面一 樣不屬於 3GPP 所制定，不一樣的是 MTC Server 是在 3GPP 網路的範圍內與 MTC Application 溝通。
本篇論文中主要探討的負載議題主要是參考 TR 23.888-1.6.1 [1]，此外為了將模擬 器修改至接近標準所定義，還參考了其他文獻[2][3][12][13]，針對標準中所提及的高負 載議題來研究，在一段允許時間 (Grant Time Interval) 中，如何讓大量的 MTC devices 連接到 3GPP 網路時降低 MME 的負載，我們提出了三種方式來處理所連接上來的 MTC devices，盡量地降低 MME 負載，分別是 Heuristic-based、Binary-based 和 Fibonacci-based 三種方法。最後在模擬結果中，我們分析了三種方式，實驗結果顯示，我們所提出的方 法可以改善 MME 的 overload 問題。
- 2 -
圖一 3GPP MTC 網路架構
1.2 議題介紹 – Time Control
在 LTE 網路的架構中，主要負責處理 device 連接的為 MME 設備，所以這篇論文是 以 MME 的角度來處理大量 MTC device 連接的問題。此外，高負載還牽涉到另外兩個 議題，Time controlled 與 Signaling Congestion Control。在 Time Controlled 中提到 MTC device 必須要有 Time Controlled 的功能，只能在預先定義的時間區間中 (GTI) 進行資料 的傳輸與接收，營運商可以依照某些準則來調整 GTI 的大小，如: 每天的流量大小，之 後 MTC device 便可以在 GTI 的時間內進行動作。
營運商另外還定義了 Forbidden Time Interval (FTI)，FTI 主要的目的是為了限制 MTC device 在 GTI 外對網路的存取，以免增加負載，另外在 FTI 中還可以進行 MTC Server 的維護，並且不能與 GTI 互相重疊，所以在 FTI 中，MME 必須拒絕所有的 MTC device 請求。通常營運商會將 MTC device 進行分類，並且為每類 MTC device 定義所屬的 GTI，
營運商必須將 GTI 通知 MTC device。
當有其他情況時還必須通知 MTC Server 和 MTC User。在 GTI 裡，每個 MTC device 對網路的存取必須要分散在這個區間中，以免造成 signaling 和 data traffic 的 peak load。
在眾多的應用中，由於 M2M 的特性，MTC device 傳輸資料的時間並不長，所以營運商 在接受 MTC device 的請求後，會定義一個 Communication Window (CW) 來讓 MTC device 來傳輸資料。
為了避免 signaling 和 data traffic 的 CW 產生 overload，MTC device 必須要分散開來，
例如隨機開始 CW 的運作。對於營運商而言，越多 MTC device 連接網路越不好，所以 當 MTC device 在 CW 結束時，營運商必須將完成工作的 MTC device 進行 detach 的動作，
- 3 -
好讓之後更多的 MTC device 可以連接上來。此外，某些應用可能會需要 MTC device 在 GTI 之外的時間連接網路，這時營運商便可以針對此種類型的應用來做不同的收費動 作。
1.3 議題介紹 – Signaling Congestion Control
另一個有關的議題為 Signaling Congestion Control，這是營運商對於 signaling 的壅 塞和負載所急需面對的問題，有關於 MTC 的 signaling congestion 和 overload 主要有三 個因素所導致:
(一) 在 MTC 應用或 MTC Server 發生故障
營運商在不影響其他 MTC device 的情況下，為了保護整個網路運作而造成的 signaling congestion。
(二) 由外部事件觸發造成大量 MTC device 一次連接到網路
在整個網路癱瘓前，營運商為了保護網路而造成的 overload 情況，營運商的保 護機制將會影響眾多的 MTC 應用。
(三) 某些 MTC 應用週期性的定期同步到網路 這種類型的應用會導致 peak load 的發生。
為了對抗 signaling congestion，MME 必須要可以拒絕或預防 MTC device 的要求，
而且要可以封鎖造成 congestion 的特定 MTC 應用，並且不影響其他的應用。應該要考 慮可以拒絕連線要求，並且不能讓被拒絕的要求馬上再重送一次，所以營運商必須要命 令 MTC device 要在一個 back off 時間之後才能再次傳送，讓 back off 時間用來改變 MTC device 的要求時間點。接下來在第二章會介紹關於問題的描述與解決方法，在第三章則 是模擬與結果分析，最後第四章為結論。
圖二 Time Control 時序圖
- 4 - 於或接近上限值，由於只有限制 MTC device 的存取，所以這個方法建議每個 MTC device 攜帶一個 MTC 指標，用來區分 MTC device 與一般的 Human-to-Human (H2H) 的裝置， MTC device 的連線請求，必須拒絕所有的連線請求，並且告知這些被拒絕的 MTC device 下一次發送請求的時間點為何時。
在每個時間點，SGSN/MME 會檢查 non-MTC device 連接上來的數量，而且與上限 值之間的差值，被用來當作 MTC device 可以連接上網路的最大值，若目前已連接的 MTC 內無法連線，那 MTC device 便會嘗試在下個 GTI 一開始傳送請求。此外，MTC device 有可能會發生一直被拒絕的情形，導致發生飢餓的狀況。在 GTI 期間內完成工作的 MTC device 應該由營運商或自行切斷連線，以便其他還未完成工作的 MTC device 可以有機 會連上網路。