LTE: Random Access 補充，競爭與非競爭的Random Access 適用範圍

有讀者張正廷問到以下的問題

我想請問 eNodeB paging UE 後，執行的 random access 是屬於 contention free 的 random access 嗎? 因為我想知道 paging 一個 UE，是否能保證他可以成功建立 RRC 連線

 

這個問題要分幾個部分去回答，也順便在原本的Random Access文章上做補充。

首先先講最終的答案。若EnodeB對UE作Paging必然是不可能保證可以成功建立RRC連線，中間會牽涉到許多Random Access的競爭關係。並非所有狀況的Random Access都可以適用於Contention Free的Random Access。

 

在 LTE: Random Access Procedure 隨機存取的文章中有提到Random Access 有分為Contention Free與 Contention Base，但是實際上在Contention Free的使用是有其限制的，並非所有的狀況都可以使用，就以下列出解釋

3gpp 36.300 subcluse 10.1.5中詳細寫著下列六種event會觸發Random Access的行為

1. 從RRC idle要初始化進行傳輸
2. RRC Connection Re-establishment，RRC連線的重建
3. Handover，基地台之間的Handover(RRC Connected)
4. 在RRC Connected狀態時，有Downlink資料要傳輸，卻需要Random Access，
5. 在RRC Connected狀態時，有Uplink資料要傳輸，卻需要Random Access，例如例如 UL synchronisation不同步或在PUCCH缺少Service Request資源時。
6. 在作定位時，例如 需要Timing Advance資訊時。

除此之外Random access procedure 分為兩種

- Contention based (適用於前五項event); 

- Non-contention based (僅適用於3,4,6 event)

所以要特別注意其中的用途跟差別

• 若是要使用Contenion Free，則是要在RRC Connected的狀態，而不能在RRC idle的狀態的情形，所以表示Paging所使用的Random Access必然是Contenion Based的。
• 使用Contenion Free 時，EnodeB會藉由RRC Reconfiguration 裡面的 rach-ConfigDedicated  去告知UE使用哪一個Preamble。

總結以上的說明，若是EnodeB Paging的狀況下，除了原本可能會有的信號遺失(例如Paging無法送到UE、UE離開現有tracking Area等等)的狀況外，也會產生無法避免的Contention Base的競爭。

LTE:Physical layer Concept (Frame structure, Resource Block and Resource Element 概念)

LTE Physical layer structure (Subcarrier and Frame Structure

OFDM and LTE Subcarrier Introduction


LTE在實體層使用OFDM作為主要調變的方式，這種調變方式因為有良好的通道適應性，相較於WCDMA的技術，增加了7%的額外系統容量，所以被廣泛用在通訊的領域中，例如xDSL、DAB、WLAN、WiMAX、LTE等，OFDM是將頻寬上面分為許多個子載波(subcarrier)，每個子載波再使用不同的調變方式去作傳輸，優點是相當的彈性，缺點就因為被切割得很細，所以容易會有額外的時間上的傳輸錯誤intersymbol interference(ISI)。或是載波頻率上的錯誤intercarrier interference(ICI),。有可能是QPSK、 16QAM、64QAM，依據狀況會使用不同的調變，若是要高可靠性就使用QPSK，若是要高傳輸速率就使用64QAM，而LTE中使用的OFDM，一個子載波的基本單位是 15KHz。

Resource Block(RB) and Resource Element(RE) Concept


在LTE高度彈性化的設計，不論是頻率、時間皆可以進行相當彈性的分配，也就是在時間與頻率上面做切割。所以必定要先提一下Resource Block及Resource Element的概念。知道一下RB是多大的單位。時間是多長，佔了多少頻寬，跟RE的關係在哪邊?
Resouce Element(RE):最小的調變單位是，佔了一個頻率上的Subcarrier，每個subcarrier是15KHz。時間上的一個Symbol。每個RE可以表示2bits、4bits或6bits。這跟調變的方式有關係。至於為什麼是這樣，這個是一個很大篇的故事，這邊就不多作介紹。不過觀念的部分可以參考這篇文章。所以RE意思即是，我在一個Symbol時間跟subcarrier的頻率範圍中。我可以傳2bits、4bits或6bits。
Resource Block(RB):既然有了RE為什麼還要定義RB呢?因為RB是使用者或是系統功能分配到的最小單位，也就是同一個RB內的功能皆是相同的，部會在一個RB內夾雜了User Data跟系統訊息等，如果映射到Physical Channel的話，每個Resource Block都是特定的Physical Channel，這樣功能才會相同。Physical channel跟RB的映射關係之後還會再詳述。

上圖為頻率、Symbol、RB、RE的示意圖，看的出來相當的清楚，RB就是84個RE，因為頻率上面是12組、在時間上面是7組，不過這邊要注意的是，這個範例是Normal Cyclic Prefix的範例，如果是Extend Cyclic Prefix，則時間上面一個Slot只能有6個OFDM Symbol，Cyclic Prefix(CP)的功用是用來防止OFDM的ISI效應產生，讓不同的symbol中間有緩衝，不要去干擾到其他的symbol，所以若是Extend Cyclic Prefix則是增加 CP的時間，讓intercarrier interference(ICI)的機會更低。
LTE Bandwidth Configuration 
根據LTE的頻寬設定，1.4MHz、3MHz、5MHz、10MHz、15MHz、20MHz會有不同的數量的RB可作分配 6,15,25,50,75,100。如同下表所示

也就是系統總共可以分配的RB數量。所以我們可以算算看一個RB最大的傳送效率是多少，每個RE最多傳送6個bits，在5ms/7的時間內。所以0.5ms之內已傳送84個RE(84*6個bits)。所以，可以得到每一個RB相當於1004kbits/sec，就是1Mbits/s左右。結論就是分到幾個RB就是幾個妹(大誤)。
由上述可知，：OFDM的技術縱橫在Time Domain與Frequency Domain，使得LTE在頻寬的使用率及彈性都大為提升，至於要怎麼去彈性使用這些資源，作為各種Physical Layer，下個主題會探討

LTE:Self Organizing Network(SON) 介紹

Self Organizing Network (SON) Concept

Self Organizing Network，自優化網路，這是一個跟UE沒有什麼太大關係的主題，這個功能是基地台自己會去優化自己的訊號。以往營運商在架設基地台需要花非常多的心思去調教基地台的功率、天線的垂直角度、天線的方向角，甚至需要一些專業的Planing Tool、Scaning tool、長時間的路測等等，就是為了要最佳化基地台的架設。在了解SON替營運商做了什麼事情之前，我們就敘述一下營運商在佈建基地台的流程

• Planning
  基地台的先期規劃，規劃基地台架設的地點，規劃基地台要打出多大的功率，天線傾角，等等參數
• Deployment
  實際下去佈建基地台，並設定基地台的參數，等工程類的動作
• Optimization
  基地台的最佳化，當基地台的量架設到一個程度，就會需要時常去最佳化基地台的配置，若沒有最佳話基地台的配置，多架設的基地台很有可能會形同虛設，設置干擾原有的基地台的訊號，造成反效果。
• Maintenence
  基地台的維護，當有訊號與計劃的不同，或是訊號不良時，要查找基地台是否損壞，天線是否偏移，設定錯誤等等動作。

可以看的出來Planning與Deployment是對於營運商初期架設的成本開銷，這種開銷通常叫做一次性的開銷，capital expenditures(CAPEX)，佈建時僅要支出一次的成本，而 Optimization與Maintenence算是經常性的開銷operational expenditures(OPEX)，意思就是維持網路就必須要不斷的開銷的成本，若是營運商能夠減少這兩個開銷，將會降低行動網路的成本，相對提高競爭力。

而SON的功能主要分為數個部分的功能

 

Hybrid Management Architecture	分層式的管理，讓管理結構化。
self-configuration	意指基地台架設初期時，自動對基地台做設定，盡量去做到plug and play，讓人工設定的部分減少，主要是降低Planning與Deployment中CAPEX的支出 。
self-optimization	則是降低Optimization與Maintencence的OPEX支出，並快速最佳化RF效能、Neighbor list。
Automated Fault Identification and Selfhealing	自動偵測基地台問題，並且自動修復。
User Perceived Quality Enhancement	自動感測使用者品質並加強。
Energy Saving	自動節能功能，在使用率較小的時段，降低整體功耗。
SON for Home eNodeB	針對Femto cell的Son，例如eICIC功能等。

 

我們就針對上述的項目進行詳細的敘述

Self-configuration

基地台的self-configuration分為下列幾個步驟，重點在plug and play，讓營運商在架設數以萬計的基地台時，不需一個一個去做設定。

1. 1. IP address allocation
   2. 設定GW，使EnodeB可以進行傳輸
   3. eNodeB將自身的硬體資訊傳送給self-configuration system，
   4. Self-configuration system會將設定資訊傳送給eNodeB，eNodeB收到之後會做自我設定。
   5. eNodeB設定完之後，會連接到OAM系統，方便維護人員做後續管理。
   6. 進行S1及X2 介面的連接，意即EnodeB與其他的EnodeB與MME做連接

Self-Optimization
重點在於Auto-Tune，自動調教基地台，讓網路達到最佳的效果

1. 基地台的self-optimization，基地台會量測附近基地台及UE的訊號，讓Self-Optimization系統有資料庫去調整EnodeB功率，達到RF的最佳化，如覆蓋率、容量等等。
2. 進行Automatic Neighbor Relation (ANR)維護Neighbor list，讓UE能夠收到正確的Neighbor list，進行正確的handover。以往這個步驟會耗用大量的人力、物力。必須要有人員使用Scanner長期進行路測、分析，並重新輸入基地台資訊，再路測，再分析，以達到最佳化。並隨著基地台的數量，會越來越複雜。最佳化的時間也越來越長，所以這個功能是相當相當重要的。
3. 進行Load Balancing，當SON發現某些EnodeB的負擔過大時，可自動去調整基地台參數，以達到Load Balancing的功能

Self-healing

對於基地台不正常的行為，會有自動偵測問題，警告，並修復之，例如某一個基地台損壞，中間的覆蓋率會由其他的基地台去補齊。這是個相當方便的功能，降低使用者因為基地台損壞或停電而造成不好的使用經驗。

 

 

可以看的出來功能相當強大，這也象徵著，未來要進入基地台研發的門檻又更高了，雖然是對於營運商更為強大，藍圖也開得不小，但是實際上能應用到什麼程度，目前我想還沒人知道。也沒人能確定。

LTE:Femto Cell Introduction

FemtoCell Concept


什麼是FemtoCell，實際上Femto cell就是一種微型的基地台，通常是擺放在家裡使用，在台灣大家聽到基地台都避之唯恐不及，但是實際上他們發射功率跟你家裏面常用的wifi AP是一樣的。也就是說你去燦坤買一台AP跟你擺一台Femto Cell在發送訊號的強度是很近似的。通常為0.1W以下。
實際上基地台有大略分成以下幾大類，主要是以發射訊號大小，以及使用者數量去做分別

基地台種類	覆蓋距離	功率	使用者數量
MacroCell	30KM	10W	More than MicroCell
MicroCell	3KM	200mW-2W	More than PicoCell
PicoCell	100M	200mW-2W	32
FemtoCell	10M	10mw-100mW	8

 
你可能會覺得Macrocell的功率比較大，比較危險。實際上Macrocell通常架設在室外，所以裝置接收到的訊號並沒有這麼強。只有在基地台附近的區域訊號較強而已。而FemtoCell與傳統基地台不同的是，他可以藉由internet去連接回原本的核心網路，等於是利用一般家庭內既有ADSL、VDSL、Cable Modem等BroadBand網路。
Data Offload and wifi Offload Concept
以往營運商通常佈建Macro Cell與MicroCell，去涵蓋大範圍的區域，等於是許多人共用相同的基地台，這樣的方式對於營運商要維運是較為容易的，且不用管理這麼多的小基地台，且以往以語音為主的服務，比較不會在意封包傳輸的速度，所以只要手機收的到，語音能通，基地台就能完成任務了。但現在的行動服務開始重視數據傳輸。當許多的人都在跟少數基地台做存取，就會造成資源不足的狀況。一般使用者就感受到手機上網不順，下載或上傳速率低落的感受。這時候營運商就得提高空中資源的複用率，就只能把基地台涵蓋範圍降低，讓大家分散去連線到不同的小型基地台裝置。於是FemtoCell跟PicoCell就開始有其價值。這件事情叫做Data Offloading。你會發現在台灣各家營運商，包括中華電信、台哥大、遠傳，都在便利商店或是公共區域佈建WIFI AP，讓有辦行動網路的用戶，不連接到大型的基地台，改連接到便利商店裡面的WIFI AP。以降低了大型的基地台的負擔，這就叫WIFI offload。


可以看到上圖，FemtoCell利用BroadBand Router及internet去連接到核心網路，提供家庭內的行動服務。進入家中或特定區域中就可以不需要連線到外面基地台，減緩外面基地台的的負擔。
FemtoCell Issue


實際在應用上，Femtocell有許多的議題是需要被解決及討論的，大部分有些已經有解決方案了，例如以下列出。有機會將會個別寫文章去

• FemtoCell與其他Cell干擾(Interference)     
  FemtoCell跟其他FemtoCell或大的基地台或會有重覆蓋問題，要如何避免。實際上有eICIC去控制干擾問題，可以參照此篇文章
• FemtoCell的存取控制(Access Control)          
  應該沒人想要自己家裡擺一台FemtoCell卻是給路人用，所以要如何做存取控制。實際上是要用Close Subscriber Group(CSG)
• FemtoCell與核心網路的連接
  因為FemtoCell是利用internet連接，所以中間的連線安全性格外重要。
• FemtoCell控管問題             
  若FemtoCell被帶至其他國家，但是其他國家同樣的無線頻段不是允許使用，這樣會造成頻段的問題

LTE:Discontinuous Reception(DRX)

Discontinuous Reception(DRX) Introduction

什麼是 Discontinuous Reception(DRX)？字面上的意思是不連續接收，意思即是UE的接收器，不會連續性的一直接收，會關閉接收器一段時間，等過一陣子再開啟，以達到UE省電的效果。在UE沒有DRX的狀況下，只能一直開著接收器去監聽基地台是否有作paging的動作，若有paging，UE則會開始與基地台從RRC idle進入到RRC connected的狀態。但若是如此，UE無時無刻開著接收器，會顯得相當的耗電，這時候就要藉由DRX的功能去降低UE開啟接收器的時間去達成省電的目的。

Short DRX Cycle and Long DRX Cycle

Long DRX Cycle

• 關閉接收器的時間較長
• 較為省電
• 使用者感受到的delay時間較長

Short DRX Cycle 

• 關閉接收器的時間較短
• 較沒這麼省電
• 使用者感受到的delay時間較短

DRX Cycle有分 Short跟Long UE可能會直接進Long Cycle或是先進一段Short Cycle再進Long Cycle，這表示Short cycle算是option。

為什麼要這樣設計呢，因為Long Cycle雖然比較省電，但是使用者在使用UE時，總是會有時間密集性，所以短時間突發的使用就讓Short Cycle來處理，而長時間的省電就由Long Cycle來處理。

Discontinuous Reception(DRX) Parameter

你一定馬上會有一個疑問，那EnodeB要怎麼知道UE什麼時候關接收器，什麼時候開接收器，要怎麼同步。如果沒有良好的同步，必定會造成很嚴重的問題。所以在基地台的RRC message 裡面就會明確指出什麼時間點要關接收器，什麼時間點要開接收器，當UE收到這些參數之後，就會跟EnodeB有默契，知道什麼時候該開，什麼時候該關。

以下則是相關的參數。

DRX Parameter	Description
DRX Cycle	定義為一次DRX的時間長度，也就是指一次打開接收器加上一次關閉接收器的時間長(這是使用Subframe time及longdrx-CycleStartOffset所計算出來的)。
onDurationTimer	這是指在DRX cycle中打開接收器的時間。
drx-Inactivity timer	表示UE在收到PDCCH的資料，還需要接收器還要開啟多久，也就是說當沒有收到PDCCH來的資料時，這個Timer就會啟動，若Timer超過設定值之後，就會接收器就會關起來，但若在這個Timer仍在計數的時候，又收到PDCCH，則這個Timer就會歸零。
drx-Retransmission timer	表示UE等候HARQ重傳時，必須監聽的最大PDCCH子訊框個數(什麼HARQ，是一個LTE錯誤重傳的機制，以後再寫。(HARQ細節的部份我們先不考量進來，不過下面有解釋DRX與HARQ的關係)
shortDRX-Cycle	DRX Cycle有分Long DRX cycle或DRX Short，這個參數表示short DRX cycle代表short DRX cycle要用多久，才會轉變成Long DRX cycle ，若是沒有設定，則直接使用Long DRX。
drxShortCycleTimer	因為有分Short DRX跟Long DRX，當超過一定的時間之後，會由Short DRX轉變成Long DRX。因為Long DRX雖然較省電，但是喚醒的時間也較久，所以LTE設計了一個機制，若是一段時間沒有資料要傳，則由Short DRX轉變成Long DRX。

Discontinuous Reception(DRX) mode in different RRC status

在不同的RRC狀態時，會有不同的DRX的表現 

先從以下的圖說起，這個圖是引用IEEE的資料

在RRC Connected時候，可以看的到，跟ACTIVE真的要傳資料並無太大的不同，最大的不同是LTE-U_u是DRX Enabled介面，所以會進行Connected節電。而在最右邊的RRC idle時，可以看的到所有的核心網路都只有把Context 保留住，但是並沒有實體做連結，而eNodeB更是把UE context移除了，所以這時候如果有要Downlink資料要傳送，核心網路會重建，並且會讓eNodeB去對UE做Paging。EnodeB做Paging的時間會選擇UE在DRX cycle的On Duration去做傳送。所以代表UE要接收到資料的時間會較長。

結論:

• Active mode DRX 用在RRC Connected狀態，使用Short DRX Cycle與Long DRX Cycle，RRC Connected表示UE與EnodeB之間是有空中資源，可以隨時進行資料傳輸，On Duration時，在聆聽的是PDCCH。
• Idle mode DRX  用在RRC Idle狀態，使用Long DRX Cycle ，RRC Idle表示UE與EnodeB之間沒有空中資源，必須透過Paging(下行)或是Random Access(上行)來取得空中資源，On Duration時是聆聽aging channel。

Discontinuous Reception(DRX) Operation

要了解DRX，必須要先從上面這張圖開始

DRX的時間為兩個，一個是On Duration，另一個則是Opportunity for DRX，On duration 是指要打開接收器的時間，Opportunity for DRX則是可以關閉接收器的部分，為什麼是Opportunity ，而不是Off Duration呢，因為要考慮到HARQ重傳的狀況。所以才會使用這個字眼。

有兩種可能會讓UE進入DRXCycle

• 在On duration接收的時候會收到從網路來的資料，當沒有從PDCCH來的資料時，就會開始Inactivity timer。這個計時器就是在算網路跟UE間多久沒有進行活動，當Inactivity timer到期的時候，就會進入DRX Cycle
• 另一種則是收到EnodeB所傳送的DRX Command MAC control element指令，則UE也會進入DRX Cycle

進入DRX Cycle之後會先有做以下的事情

• 會將onDurationTime與drx-InactivityTimer，因為這都是On Duration 所需的計時器。
• 判斷是否有Short DRX cycle ，若是有的話，則使用Short DRX，若是沒有的話，則是使用Long DRX Cycle，還記得前面提到Long DRX與Short DRX的差別嗎，是這是使用Subframe time及longdrx-CycleStartOffset所計算出來的。會有這樣的設計，UE通常剛進入DRX會有很高的機會再收到資料，當處於Short DRX cycle一段時間沒傳資料之後，才會進入Long DRX Cycle。

進入Long DRX Cycle時，符合以下的條件會打開接收器監聽訊號

( [(SFN * 10) + subframe number] mod (longDRX_Cycle)  == (drxStartOffset) ) 

• [(SFN * 10) + subframe number] 這個東西代表每個subframe的系統絕對位置，Frame的架構以後再寫吧，這邊寫就扯遠了。
• mod代表除某個東西的餘數
• LongDRX_Cycle是網路給的Long DRX Cycle數值
• drxStartOffset代表是在哪個訊框開始的，我可以在某個訊框開始週期

整段的意思就是如果我在某些訊框剛好是Long DRX Cycle時才會開起來，因為Long DRX 數值通常比較大，所以開起來的次數當然明顯比較少，一到一萬除於100能整除的數字一定比除於10的數字少。

進入Short DRX Cycle，符合以下的條件會打開接收器監聽訊號

( [(SFN * 10) + subframe number] mod (shortDRX_Cycle) == (drxStartOffset) mod (shortDRX_Cycle))

• [(SFN * 10) + subframe number] 這個東西代表每個subframe的系統絕對位置，Frame的架構以後再寫吧，這邊寫就扯遠了。
• mod代表除某個東西的餘數
• ShortDRX_Cycle是網路給的Short DRX Cycle數值
• drxStartOffset代表是在哪個訊框開始的，我可以在某個訊框開始週期
• 為什麼右邊是還會除餘shortDRX_Cycle，老實說我不清楚，也找不到原因，只知道如果除餘一個數字會讓 Long DRX跟 Short DRX的offset會不同。

因為Long DRX 數值通常比較大，所以開起來的次數當然明顯比較少，一到一萬除於100能整除的數字一定比除於10的數字少。

Discontinuous Reception(DRX) and HARQ Relation 

但要注意一件事情，也就是我們中間有提到的HARQ重傳機制會如何影響到DRX的機制

鑒於很多資料都不清楚，我用以下一張圖來說明HARQ與DRX的關係(僅為概念圖)

可以看到上圖有一個HARQ RTT Timer也有一個DRX Retransmission timer，HARQ RTT timer表示 HARQ的重傳最快什麼時候會回來，在發生HARQ解碼錯誤，通常是傳送過程被影響，於是會啟動HARQ RTT Timer，而且必定是HARQ RTT timer結束之後HARQ重傳才會到，代表這中間都還可以不理會繼續做DRX。而DRX-Retransmission timer為 HARQ RTT timer結束之後會開啟，當開啟之後，就會暫停DRX的機制，等待重傳，等到Retransmission time結束後就會回歸DRX機制。這是為了重傳而設計的機制

重點:只有在drx-InactivityTimer和drx-RetransmissionTimer都不啟動時，UE才會關閉接收器。也就是說InactivityTimer時間到了，但RetransmissionTimer還在跑，還是要乖乖的把接收器打開來等待HARQ機制重傳

 

HARQ後記

看了這麼多，可以發現協會開放了這麼多的參數，就是要給每個營運商自己去控制UE的省電程度與開啟DRX之後的延遲程度，所以到最後還是把這個調整的課題留給營運商!

LTE: TRACKING AREA UPDATE REQUEST 詳解

Tracking  Area Update(TAU) Conecpt

Tracking Area Update是UE用來更新自己在基地台區域位置的一個信令，目的是要讓基地台知道UE目前移動到哪個區域位置。詳細概念請參照這裡。你一定會問另外一個問題，UE要怎麼知道自己是在哪個Tracking Area。UE是靠著EnodeB的System information Block 1(SIB1)去得到自己的tracking Area。所以UE收到新的EnodeB的廣播訊息，他就會檢查Tracking Area Code。

When Tracking Area Update (TAU) Occur

在以下的狀況下，UE會使用Tracking Area Update (TAU)

• Normal TAU: 當UE進入到新的tracking area時，而這個tracking area不是在自己的tracking area list裡面，這時候UE會進行TAU，來讓MME知道UE進到新的tracking area。
• Combined TAU: 如果UE在CS/PS mode 1 或CS/PS mode 2時，也就是運作在有CS Fallback時，當UE進到一個新的Tracking Area時，他會進行Combined TAU，同時更新Tracking Area與WCDMA、GSM的Location Area(LA)。因為CS Fallback，Device要隨時能找的到2G、3G的基地台去使用Circuit Switched Service來撥打電話。CS Fallback相關資訊請參照這篇
• Periodic TAU: 定時TAU，UE在T3412定時器的時間到時，會做TAU update。因為UE有可能很長時間在同一個Tracking Area，所以一般會讓UE定期去做一個Tracking Area update，讓MME知道UE還活著。
• 在inter-RAT的狀況，UE在切換不同的technology時，都會進行tracking area update。
• MME load balancing: 當UE接收到EnodeB的 RRC CONNECTION RELEASE 訊息，並內含cause code "load balancing TAU required'", UE必須要進行TAU的程序，讓新的MME確認UE本身Trackin Area。
• 向網路更新UE使用的某一些使用參數，例如UE network capability information或the “MS network capability或DRX parameter等等。

Tracking Area Update Request  signaling Detail

  M=Mandotory，O=Optional

Information Element	Presense	Description
Security header type	M	表示本NAS message 是否有Integrity(完整性)及Ciphered(加密)， 要經過Security Command才會有功能，不然為0000全零，未加密。
EPS update type	M	用來指示update 的型態，可能為以下的其中一種，詳細請參閱最上面的說明 TA updating combined TA/LA updating’ combined TA/LA updating with IMSI attach periodic updating 除了指示update型態之外，如果UE當下有另外的data要傳而尚未傳送，可以再active flag裡面指示，則網路在做完TAU程序之後，也就是，會對UE的進行Bearer establishment。簡單的說就是讓網路端知道UE有要傳送資料。以節省額外的信令。
NAS key set identifier	M	用來指示目前UE上有什麼NAS Security Key。是KSIASME或是映射到的KSISGSN，因為對安全性沒什麼概念，這邊不太了解，詳細資料在24.301 subclause 4.4.2
Old GUTI	M	UE支援A/Gb mode(2G)或 lu mode(3G) TIN 為 P-TMSI 並且 UE有 P-TMSI 及RAI時, 則UE 必須將Old GUTI欄位設為 P-TMSI 及 RAI 並將Old GUTI type 設定為mapped GUTI. 若UE擁有合法的GUTI則必須設定額外設定 Additional GUTI - If TIN 為GUTI或RAT-related TMSI 並且the UE擁有合法的GUTI, the UE必須將Old GUTI 設定為GUTI並且在Old GUTI type中設為native GUTI。 UE不支援A/Gb mode(2G)或 lu mode(3G) : UE 必須附加GUTI並且在Old GUTI type中設為native GUTI。
Non-current native NAS key set identifier	O	若UE從A/Gb mode或lu mode 轉換到S1 mode時，若有既有的native NAS key set，則要在這邊標註擁有何種EPS security context。
GPRS ciphering key sequence number	O	當UE由 A/Gb mode(2G)或lu mode(3G)轉換到S1 mode(4G)時，且在EMM idle mode及TIN 為P-TMSI時，就要附上GPRS ciphering keysequence number。
Old P-TMSI signature	O	如果UE上有P-TMSI就要在這邊告知網路，P-TMSI，為3G或2G在packet domain使用的temp id，這是用做Idle state Signalling Reduction(ISR)所使用。
Additional GUTI	O	一樣是Idle state Signalling Reduction(ISR)時使用，TIN若是使用P-TMSI，並且UE有GUTI、P-TMSI及RAI。
NonceUE	O	當UE由 A/Gb mode(2G)或lu mode(3G)轉換到S1 mode(4G)時，就要附上NonceUE，讓網路端知道UE目前使用的Nonce，藉以生成新的EPS security context。
UE network capability	O	此為UE用來傳送自己能力給網路端，包括 UE本身加密的能力EEA0-EEA7'、EIA0-EIA7、UEA0-UEA7等等 access class control for CS Fallback(22.011) LTE Location Service(24.171) LTE Positioning Protocol (LPP) (36.355) 1xSRVCC(23.216)
Last visited registered TAI	O	UE上次註冊的Tracking Area Indicator
DRX parameter	O	用來指示網路端UE所使用的DRX(Discontinuous Reception) parameter，雖然DRX是UE定期關閉接收器已作省電之用的功能，但Network仍需要知道UE DRX的時機，以達到最佳的效果。
UE radio capability information update needed	O	The UE shall include this IE if the UE radio capability information in the network needs to be updated.
EPS bearer context status	O	用來指示MME，現在UE目前有哪些EPS bearer。若MME收到發現，目前UE上並沒有相對應的EPS bearer，.他會自行將UEinactive的EPS bearer刪除。
MS network capability	O	UE用作傳送GPRS相關能力的欄位 GEA algorithms能力，GEA1-GEA7 是否支援SMS over CS domain 是否SMS over PS domain 是否支援UCS2 encoding for SMS 是否支援ISR 詳情請參照 24.008 subclause 10.5.5.12
Old location area identification	O	如果UE使用combined tracking area update，就要附上原有正確的Location Area 資訊，這也是因為CSFB才有需要的功能，請參照CSFB。
TMSI status	O	如果UE在做combined tracking area update沒有TMSI存在就必須在此指示
Mobile station classmark 2	O	包含UE在GSM及WCDMA中所支援的RF能力24.008 subclause 10.5.1.6
Mobile station classmark 3	O	包含UE在GSM及WCDMA中所支援的RF能力，包括multiband等等更多欄位，詳細在24.008 subclause 10.5.1.7
Supported Codecs	O	如果UE支援SRVCC時，要在這邊列出在GERAN(2G)及UTRAN(3G)支援的codec，支援的codec列表在26.103，格式在24.008 subclause 10.5.4.32
Additional update type	O	在combined attach(CS fallback)時提供額外的資訊，0代表沒有額外的資訊，1代表 SMS only，代表可使用LTE NAS傳送SMS給MME，MME再傳送給MSC，這個feature叫做SMS over SGs，可以參考以下網頁。
Voice domain preference and UE's usage setting	O	This IE shall be included if the UE supports CS fallback and SMS over SGs, or f the UE is configured to support IMS voice, but does not support 1xCS fallback. 如果UE支援 CS fallback與 SMS over SGs就必須在這邊標明以下資訊 UE's usage setting:Voice Centric 或Data Centric 定義在23.221 subcluse7.2a 或參照這裡 voice domain preference:CS Voice only、IMS PS Voice only、優先CS voice或優先IMS PS。

 

Tracking Area Update Request 其實相當單純，最主要複雜的部分還是在於要跟3G/2G做TA/LA comibned updated，加上UE上的TIN設定，會讓UE在回傳自己的identity時會回傳不同的資訊。另一點跟attach一樣，會有相當多的UE Voice資訊提供給網路，讓網路可以做Voice Service的判斷。

LTE: ICIC(Inter-cell interference coordination) 與 eICIC (enhanced Inter-cell interference coordination)

WHY ICIC and eICIC

• LTE的Frequency reuse factor為1，據說是為了增加頻率使用效率(未查證)，表示每個基地台都使用相同的頻寬，意思就是在基地台邊緣的手機，會同時接收到兩個基地台甚至數個基地台的訊號，而且都是相同的頻率。所以在基地台邊緣的手機有很高的機會被其他的基地台訊號干擾。
• 對於一般的traffic，可以承受高的封包錯誤率。頂多是速度慢，但若是control channel若是高封包錯誤率，會導致手機嚴重斷訊。
• 若是 Heterogeneous networks 則會對Frequency Reuse更敏感，因為大的Marco Cell會整個覆蓋大區域至十公里以上，而以街道為單位的pico cell或以辦公室為單位的Femto cell，則會整個被Macro cell干擾，因為用的是同一頻率!

ICIC (Inter-cell interference coordination) 

3GPP release 8時提出Inter-cell interference coordination(ICIC) 解決方案，目的在解決上述的基地台邊緣干擾問題。解決方式是利用eNodeB與eNodeB之間的X2去協同溝通資源。但僅限於降低traffic Channel的干擾，而沒有對control channel處理

• ICIC使用功率大小與頻率動態分配的方式去降低基地台間的干擾
• 在鄰近的基地台同樣的時間使用不同的Resource Block(RB)。也就是說鄰近的基地台不會指派同一個RB。好處是，因為分派給UE的RB不同，當然就不會產生干擾。壞處就是會降低一個基地台的傳輸速率。
• 第二種方式是僅有基地台邊緣的UE才會分配不同的RB，而離基地台近的UE還是使用整個完整頻寬
• 第三種方式則是比第二種更多了power的控制，當基地台會特別增強在邊緣UE使用的RB的Power。當然，這些RB，也是非鄰近基地台所使用，而離基地台較近的UE，他們所收到的RB還是會以較低的功率發送。

eICIC (enhanced Inter-cell interference coordination)

3GPP release 10時，提出了eICIC，也就是增強型的eICIC。最主要是解決HetNet(Heterogeneous Networks) interference，也就是異質網路的干擾，但重點是，同時降低traffic channel及control channel的干擾，才會比較有效。如果是macro cell使用X2去設定，而femto則是使用OAM去設定。

• eICIC 除了使用功率大小、頻率分配，另外也使用時間分配的方式去降低干擾。
• eICIC在時間分配上，多了一個ABS(Almost blank subframe)，就是在解決HetNet的干擾問題，在ABS的frame中，Macro Cell不送任何traffic，最多僅能送及低功率的control frame。而在這些frame之中，安插不同UE的traffic channel，就可以讓femto或pico cell去傳輸他們的traffic channel。

LTE IP分配 (LTE IP address allocation)

透過Attach request與attach accept的步驟。UE除了得到EPS Bearer之外，UE同時也必須要取得IP，用以透過PDN Gateway去跟IP network傳輸。但因為UE在attach過程中還沒有IP的能力。這時只能藉由NAS去讓UE取得IP。我們現在就是要介紹LTE EPC如何去協助UE取得IP。

UE跟網路取得IP的方式

• IPv6  stateless address autoconfiguration
  網路給UE prefix，讓UE加上自己的interface ID，就可以形成一個IPv6的address，而DNS server address的部分則是使用ESM去取得。
• Stateless DHCPv6
  網路給UE prefix，但是DNS則由DHCP取得。
• DHCPv4
  若是使用DHCPv4，網路會assign address給UE 0.0.0.0，再讓UE去使用DHCPv4去取得IP

注意:不支援stateful IPv6的取得。

UE支援的IP型態

• IPv4
  如果UE只支援IPv4，在PDN type欄位要設定IPv4
• IPv6

  如果UE只支援IPv6，在PDN type欄位要設定IPv6

• IPv4v6
  如果UE同時支援IPv4及IPv6或不知道支援性，則PDN type必須要設定IPv4v6

在UE做PDN connection request的時候，會指定PDN type，並且在protocol configuration  options附上偏好取得IP的方式。網路收到之後，會參考網路相關的偏好去回給UE。例如雖然UE要求IPv4 但是網路僅支援IPv6，則網路會拒絕UE的連線，而當UE要求IPv4v6的時候，若網路只支援IPv4，那只會回給UE僅支援IPv4。IPv6亦是如此
實務上通常營運商會規定手機連上PDN要用什麼PDN type。

何時取得IP

ESM(EPS Session Management)訊息中做交換，藉由PDN連線時，同時進行。利用下面兩個步驟去協調IP取得的方式

UE -->PDN connection request (PDN Type、Protocol configuration options)--> MME

UE <-- Activate Default EPS Bearer Context Request(PDN Type、Protocol configuration options) <-- MME

 

Note:在同一個PDN 連線用的IP都一樣，所以同一個不管是default bearer 或dedicated bearer都是使用同一個IP

UE有下列幾種方式取得IP

a) 由HPLMN 分配IP (dynamic or static HPLMN address)

b) 由VPLMN 分配IP (dynamic VPLMN address)

c) 由PDN operator 去分配

參考資料:

24.301 subclause 6.2

23.401 subclause 5.3.1