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相关的承载资源。