LTE 中基於X2的切換 （36.300, 23.401）SGW 保持不變
http://blog.sina.com.cn/s/blog_673b30dd0100j4pe.html
1：eNodeB為UE配置測量報告的參數。是通過RRCConnnectionReconfiguration中的Measurement Configuration IE 來實現的。
measConfig
{
measObjectToAddModList
{
{
measObjectId 1,
measObject measObjectEUTRA :
{
carrierFreq 5230,
allowedMeasBandwidth mbw6,
presenceAntennaPort1 FALSE,
neighCellConfig '00'B,
cellsToAddModList
{
{
cellIndex 1,
physCellId 116,
cellIndividualOffset dB0
}
}
}
}
},
reportConfigToAddModList
{
{
reportConfigId 1,
reportConfig reportConfigEUTRA :
{
triggerType event :
{
eventId eventA3 :
{
a3-Offset -7,
reportOnLeave TRUE
},
hysteresis 2,
timeToTrigger ms128 發送測量報告前，測量條件必須連續滿足的時間。
},
triggerQuantity rsrp,
reportQuantity sameAsTriggerQuantity,
maxReportCells 2, 除服務小區外，測量報告中包含的最多小區數目。
reportInterval ms1024,如果eNodeB沒有相應初始的測量報告，UE再次發送測量報告的周期。再次報告時，需要仍然滿足報告條件嗎？
reportAmount r64 如果eNodeB沒有響應初始的測量報告，UE發送再次測量報告的數目。
}
}
},
measIdToAddModList
{
{
measId 1,
measObjectId 1,
reportConfigId 1
}
}
},
在Measurement Configuration中，以 Measurement ID來標識每個測量，每個測量包含 Measurement Object 和 Report Configuration兩個部分， Measurement Object 定義了UE需要測量的目標，Report Configuration則定義了觸發測量報告的事件。在LTE中，測量報告的發送可以是事件觸發的，或周期發送的，或事件觸發周期發送的。
觸發測量報告的事件主要有以下幾種：
A1： 服務小區的測量值高於預定的測量門限（對於EUTRAN來說，測量值包括RSRP和RSRQ）。
A2： 服務小區的測量值低於預先設定的測量門限。
A3： 相鄰的EUTRA小區的測量值優於目標小區 ＋ 預定的偏移量。
A4 ：相鄰的EUTRA小區測量值高於預定的測量門限。
A5：服務小區的測量值低於預先設定的測量門限並且相鄰小區的測量值高於另一預定的測量門限。
B1：Inter RAT的鄰小區測量值高於預定的測量門限。
B2：目標小區低於預先設定的測量門限並且Inter RAT的鄰小區測量值高於另一預定的測量門限。
2：這樣當測量報告條件滿足后， UE就會向eNodeB發送測量報告。
message c1 : measurementReport :
{
criticalExtensions c1 : measurementReport-r8 :
{
measResults
{
measId 1,
measResultServCell
{
rsrpResult 56,
rsrqResult 14
},
measResultNeighCells measResultListEUTRA :
{
{
physCellId 116,
measResult
{
rsrpResult 54
}
}
}
}
}
}
3：源eNodeB根據RRM信息和UE上報的測量報告決定進行切換。
LTE中的切換都是硬切換，也就是說，在接入新的eNodeB之前，斷開與原有eNodeB之間的連接。LTE不支持軟切換，不存在激活集的概念。
根據源eBodeB 和目標eNodeB是否連接到同一個MME(池,MME Pool）以及他們之間是否存在X2連接，LTE中的切換，可以划分為基於X2的切換和基於S1的切換。LTE中，將缺省進行基於X2的切換，除非源和目標eNodeB之間不在同一個MME（池）的范圍或者不存在X2連接或者源eNodeB配置成需要進行基於S1的切換。
在基於X2的切換過程中， EPC中的MME(池)保持不變，而與之相連的SGW則有可能發生改變。
在基於X2的切換過程中，切換過程（包括信令和用戶面數據）是在兩個eNodeB之間直接進行的，切換時延相對較小。在切換成功的最后才通知MME，以進行路徑的切換。
在基於X2的切換過程中，源eNodeB資源的釋放是由目標eNodeB直接觸發的。
.在基於X2的切換過程中，可以對每個EPS承載采用不同的轉發機制。（無縫切換和無損切換）
4 ：源eNodeB決定進行基於X2的切換，通過X2接口向目標eNodeB發送Handover
Request 消息， 包括如下信元（IE）。
| IE/Group Name |
Presence |
| Message Type |
M |
| Old eNB UE X2AP ID |
M |
| Cause |
M |
| Target Cell ID |
M |
| GUMMEI |
M |
| UE Context Information |
|
| > MME UE S1AP ID |
M |
| > UE Security Capabilities |
M |
| >AS Security Information |
M |
| > UE Aggregate Maximum Bit Rate |
M |
| > Subscriber Profile ID for RAT/Frequency priority |
O |
| >E-RABs To Be Setup List |
|
| >>E-RABs To Be Setup Item |
|
| >>> E-RAB ID |
M |
| >>> E-RAB Level QoS Parameters |
M |
| >>> DL Forwarding |
O |
| >>> UL GTP Tunnel Endpoint |
M |
| >RRC Context |
M |
| >Handover Restriction List |
O |
| >Location Reporting Information |
O |
| UE History Information |
M |
| Trace Activation |
O |
| SRVCC Operation Possible |
O |
其中Old eNB UE X2AP 將X2AP通道在源eNodeB側的標識通知目標eNodeB，以建立兩個eNodeB之間的X2AP通道。UE Context Information信元中的ERAB List中包含上行的GTP Tunnel在SGW側的TEID，目標eNodeB將根據此TEID值在步驟11向（源）SGW發送數據。
5：目標eNodeB根據接收到的 E-RAB的QoS屬性進行接入控制判斷，如果允許接入，
目標eNodeB將根據E-RAB的QoS屬性預留相應的資源，分配C－RNTI以及隨機接入的專用前導序列等。
6：目標eNodeB進行L1/L2層的切換准備工作，會向源eNodeB發送Handover Request Acknowledge 確認。 在此消息中，與接入目標eNodeB有關的相關RRC信令作為Transparent Container也包含在其中。
7：源eNodeB將目標eNodeB生成的RRCConnectionReconfiguration消息（包含MobilityControlInfo信元），發送給UE，其中包括目標小區的物理標識，UE在目標小區中的C－RNTI，目標小區接入的專用前導序列，目標小區的安全算法等。
message c1 : rrcConnectionReconfiguration :
{
rrc-TransactionIdentifier 0,
criticalExtensions c1 : rrcConnectionReconfiguration-r8 :
{
mobilityControlInfo
{
targetPhysCellId 116,
t304 ms2000,
newUE-Identity '00000111 11100000'B,
radioResourceConfigCommon
{
rach-ConfigCommon
{
preambleInfo
{
numberOfRA-Preambles n52
},
powerRampingParameters
{
powerRampingStep dB2,
preambleInitialReceivedTargetPower dBm-104
},
ra-SupervisionInfo
{
preambleTransMax n6,
ra-ResponseWindowSize sf10,
mac-ContentionResolutionTimer sf64
},
maxHARQ-Msg3Tx 1
},
prach-Config
{
rootSequenceIndex 22,
prach-ConfigInfo
{
prach-ConfigIndex 14,
highSpeedFlag FALSE,
zeroCorrelationZoneConfig 5,
prach-FreqOffset 0
}
},
pusch-ConfigCommon
{
pusch-ConfigBasic
{
n-SB 1,
hoppingMode interSubFrame,
pusch-HoppingOffset 0,
enable64QAM FALSE
},
ul-ReferenceSignalsPUSCH
{
groupHoppingEnabled FALSE,
groupAssignmentPUSCH 0,
sequenceHoppingEnabled FALSE,
cyclicShift 0
}
},
ul-CyclicPrefixLength len1
}
},
radioResourceConfigDedicated
{
physicalConfigDedicated
{
schedulingRequestConfig setup :
{
sr-PUCCH-ResourceIndex 0,
sr-ConfigIndex 154,
dsr-TransMax n4
}
}
},
securityConfigHO
{
handoverType intraLTE :
{
securityAlgorithmConfig
{
cipheringAlgorithm eea0,
integrityProtAlgorithm spare1
},
keyChangeIndicator FALSE,
nextHopChainingCount 1
}
}
}
}
8： 對於需要進行無損傳輸的DRB（數據承載），源eNodeB發送SN STATUS TRANSFER消息給目標eNodeB，包括針對需要保持PDCP的E－RAB（例如RLC AM模式）的上行PDCP的接收狀態，和下行PDCP的發送狀態。目的是為了保證切換過程中的無損數據傳輸。此時源eNodeB開始轉發用戶面數據給目標eNodeB。根據切換類型的不同（無縫切換還是無損切換），數據轉發的機制也有所不同。（詳見關於無縫切換和無損切換的討論。）目標eNodeB將源eNodeB轉發的數據進行緩存。
9：接收到RRCConnectionReconfiguration消息后，UE從源eNodeB中去附着，然后通過隨機接入過程與目標eNodeB建立同步。（LTE中，為了簡化起見，eNodeB內的不同Cell之間的切換和eNodeB之間的切換是統一對待處理的。），如果在步驟7中接收到專用的隨機接入前導序列，則采用無競爭的隨機接入過程，否則采用基於競爭的隨機接入過程。
10：目標eNodeB返回給UE上行的資源分配及時間同步信息。
11：UE發送RRCConnectionConfigurationComplete消息給目標eNodeB，確認切換成功。此時UE和目標eNodeB之間進行數據的上，下行傳輸。目標eNodeB開始將上行數據轉發給SGW，此時目標eNodeB並不知道此次切換是否要進行SGW的Relocation，只是將上行數據轉發給從源eNodeB獲得的源SGW，此時由於到目標eNodeB的下行隧道尚未建立，因而下行的數據仍然需要通過源eNodeB轉發到目標eNodeB。
12：目標eNodeB發送Path Switch Request消息給MME，將UE已經進行了小區切換的信息通知給MME。其中包括目標小區的TAI ＋ ECGI 以及被目標小區拒絕的EPS承載列表（如果有的話）。目標eNodeB的下行TEID值是此時通知給MME。
(29.274)
| IE/Group Name |
Presence |
| Message Type |
M |
| eNB UE S1AP ID |
M |
| E-RAB To Be Switched in Downlink List |
M |
| >E-RABs Switched in Downlink Item IEs |
|
| >>E-RAB ID |
M |
| >>Transport layer address |
M |
| >>GTP-TEID |
M |
| Source MME UE S1AP ID |
M |
| E-UTRAN CGI |
M |
| TAI |
M |
| UE Security Capabilities |
M |
13：MME認為SGW可以保持不變，發送UPDATE USER PLANE REQUEST（Modify Bearer Request）消息給SGW，其中包括用戶S1 GTP－U在目標eNodeB側的FTEID值。
14：SGW不再向源eNodeB發送UE的用戶面數據，將下行的數據切換到目標eNodeB側，由於SGW保持不變，因此不需要SGW與PGW之間的信令交互。SGW發送一個或多個“END Marker”數據包給源eNodeB。源eNodeB將“End Marker”消息轉發給目標eNodeB。End Marker數據包不含有任何的數據，在GTP的頭部表明是End Marker數據包，指示對應的GTP Tunnel上的數據傳輸結束。隨后，SGW釋放掉到源eNodeB的用戶面資源。此時UE與PGW之間的上，下行GTP－U通道都經過目標eNodeB了。
15： SGW發送 “UPDATE USER PLANE RESPONSE” （Modify Bearer Response）消息給MME。
16： MME發送“PATH Swith ACK”消息給目標eNodeB。
17：收到MME的上述消息后，目標eNodeB發送“UE Context Release”消息給源eNodeB，通知源eNodeB切換成功，可以釋放相關資源。
18：接收到消息后，目標eNodeB開始釋放相關資源。
LTE 中基於X2的切換 （36.300, 23.401）SGW Relocate
http://blog.sina.com.cn/s/blog_673b30dd0100j4pj.html
上文的信令流程是SGW在切換前后保持不變的情形。如果MME認為需要重新定位SGW （Relocate）， 則其信令流程如下圖所示。圖中假定目標eNodeB和源SGW之間存在IP連接（否則，即認為需要進行基於S1的切換），這樣，在UE發送RRCConnectionReconfigurationComplete消息，接入到目標eNodeB后，上行的數據就可以通過目標eNodeB向源SGW和PGW進行發送（通過Handover Request消息，目標eNodeB獲得了源SGW的上行GTP Tunnel的TEID值）。當然，目標SGW和目標eNodeB之間以及源SGW和源eNodeB之間的IP連接是存在的。（否則無法建立通常的GTP－U隧道）。
1：目標eNodeB發送Path Switch Request消息給MME， MME根據相應的准則，選擇了一個與源SGW不同的目標SGW。（注： MME是根據TA（Tracking Area）的粒度來選擇SGW的，SGW不同，意味着TA發生了變化， 隨后需要進行TAU的過程？？？）。
2：MME發送Create Session Request消息給新的SGW, (Create Session Request消息包含的內容參見EPS Initial Attach 過程)，與EPS Initial Attach過程不同，下行GTP－U隧道在目標eNodeB側的TEID值也包括在此消息中。
3：目標SGW為下行數據分配TEID， 並向PGW發送Modify Bearer Request消息。PGW更新相應的信息，返回Modify Bearer Response消息給SGW。此時PDW已經獲得與目標SGW以及目標eNodeB相連的下行GTP－U隧道信息，因而開始通過新的GTP隧道傳送下行數據。
4：目標SGW發送Create Session Response消息給MME。通知MME上行GTP－U隧道的FTEID值。MME啟動定時器，在步驟7使用
5：MME回應Path Switch Request Ack消息給目標eNodeB， 此時目標eNodeB獲得了與目標SGW以及PGW相連的上行GTP－U隧道信息，因而開始通過新的GTP隧道來發送上行數據。
6：目標eNodeB發送UE Context Release消息給源eNodeB, 通知源eNodeB切換成功，源eNodeB可以刪除相關的資源。
7：4中的定時器超時后，MME發送Delete Session Request消息給源SGW， 釋放與源SGW相關的承載資源。