LTE Initial Attach 过程 1.docx
《LTE Initial Attach 过程 1.docx》由会员分享，可在线阅读，更多相关《LTE Initial Attach 过程 1.docx（20页珍藏版）》请在冰豆网上搜索。
LTEInitialAttach过程1
LTE Initial Attach 过程
（1）
（2014-10-1616:
26:
03）
转载▼
标签：
转载
原文地址：
LTE Initial Attach 过程
（1）作者：
lte2010
UE开机，通过小区选择和小区重选，驻留到合适的小区后，就进行”InitialEPSAttach”的过程。
通过初始EPS附着，UE可以在EPS网络进行分组域服务的注册，同时，建立缺省的EPS承载，进行用户数据的传输。
（3GPP23.401和29.274）。
步骤1:
messagec1:
rrcConnectionRequest:
{
criticalExtensionsrrcConnectionRequest-r8:
{
ue-IdentityrandomValue:
'11110111010011100000001010000110100...'B,
establishmentCausemo-Signalling,
spare'0'B
}
rrcConnectionReqest是在SRB0上传输的，SRB0一直存在，用来传输映射到CCCH的RRC信令。
在此消息中，UE-Identity的目的是为了底层随机接入的竞争消除。
它可以是S－TMSI，也可以是UE生成的随机数。
在InitialEPSAttach的过程中，UE还没有获得S－TMSI，因此包含了一个40位的随机值。
NAS层通过establishmentCause指明连接的原因。
步骤2：
RRCConnectionSetup
messagec1:
rrcConnectionSetup:
{
rrc-TransactionIdentifier0,
criticalExtensionsc1:
rrcConnectionSetup-r8:
{
radioResourceConfigDedicated
{
srb-ToAddModifyList
{
{
srb-Identity1,
rlc-ConfigurationdefaultValue:
NULL,
logicalChannelConfigdefaultValue:
NULL
}
},
mac_MainConfig
{
...
}
physicalConfigDedicated
{
。
。
。
}
}
}
}
通过底层的竞争接入冲突解决机制，UE接收到NodeB的rrcConnectionSetup信令，建立了UE与ENodeB之间的SRB1，NodeB为SRB1配置RLC层和逻辑层信道的属性。
ENodeB还可以在此信令中对MAC层和物理层进行配置，如果NodeB没有对此进行配置，36.331中定义了MAC层和物理层的缺省值。
UE收到NodeB的rrcConnectionSetup信令后，UE和NodeB之间的SRB1就建立起来了。
步骤3：
RRCConnectionSetupComplete
UL-DCCH-Message=
message=c1=rrcConnectionSetupComplete=
rrc-TransactionIdentifier=0
criticalExtensions=c1=rrcConnectionSetupComplete-r8=
selectedPLMN-Identity=1
dedicatedInfoNAS=。
。
。
在UE接收到RRCConnectionSetup消息后，向NodeB发送一个RRCConnectionSetupComplete消息。
其中，selectedPLMN-Identity表示UE选中的PLMN在SIB1中广播的PLMNList中的序号值。
RRCConnectionSetupComplete消息中的dedicatedInfoNAS包含了NAS层的信令，在EUTRAN中UE的初始接入过程中，NAS层信令通常是EMM层的AttachRequest消息和ESM层的PDNConnectivityRequest消息。
Msg
aTTACH_REQUEST
securityHeaderType='0000'B
protocolDiscriminator='0111'B
messageType='01000001'B
nasKeySetId
iei=Omit
tsc='0'B
nasKeySetId='111'B
epsAttachType
spare='0'B
typeValue='001'B
oldGutiOrImsi
iei=Omit
iel='0B'O
idDigit1='1111'B
oddEvenInd='0'B
typeOfId='110'B
otherDigits='00F11000010112345678'O
ueNetworkCapability
iei=Omit
iel='02'O
networkCap='C0C0'O
esmMessage
iei=Omit
iel='0005'O
esmPdu='0201D031D1'O
oldPtmsiSignature=Omit
additionalGuti=Omit
lastVisitedRegisteredTai
iei='52'O
plmnId='00F110'O
tac='0001'O
drxParameter=Omit
msNetworkCapability=Omit
oldLai=Omit
tmsiStatus=Omit
msClassmark2=Omit
msClassmark3=Omit
supportedCodecList=Omit
PiggybackedPduList
NAS_UL_Pdu_Type
Msg
pDN_CONNECTIVITY_REQUEST
epsBearerId='0'H
protocolDiscriminator='0010'B
procedureTransactionIdentifier='01'O
messageType='11010000'B
pdnType
spare='0'B
typeValue='011'B
requestType
spare='0'B
typeValue='001'B
esmInfoTransferFlag
iei='D'H
spare='000'B
eitValue='1'B
accessPointName=Omit
protocolConfigurationOptions=Omit
PiggybackedPduList=Omit
在AttachRequest中，oldGutiOrImsi会被MME用来在HSS中查询用户的签约信息。
其中=。
M－TMSI是32位的在MME内UE的ID。
而=
=
MMGI＝MMEGroupID，MMEC＝MMECode。
由于RRCConnectionSetupComplete消息是明文传送的，为了保护IMSI的私密性，应尽量减少IMSI在空口传播，GUTI的使用就是为了这个目的。
当然，手机初始附着，由于不存在OldGUTI，还是会发送一次IMSI。
如果eNodeB给UE找到的MME不是之前detach那个MME，新的MME将通过oldGUTI找到旧的MME（即上次detach时的MME），再发送IdentificationRequest（GTP-C）消息给旧的MME以获得手机的IMSI。
这个IdentificationRequest消息包含oldGUTI和完整的Attach请求消息。
如果（新的）MME仍然无法得到UE的IMSI，MME会发送IdentityRequest消息给UE,要求UE上报自己的IMSI。
drxParameter指明UE特定的DRX相关参数。
UE通过此参数通知EUTRAN自己特定的寻呼周期,系统广播消息SIB2中的PCCHConfig参数中也定义了缺省的寻呼周期,在这种情况下,UE使用两者中的最小值。
lastVisitedRegisteredTai用来帮助MME生成有效的TAI列表，MME将在AttachAccept消息中返回给UE。
ueNetworkCapability包含NAS和AS的安全参数
pdnType表示PDN连接的IP类型。
（IPv4、IPv6或者IPv4/IPv6）
步骤4：
InitialUEMessage
eNodeB接收到RRCConnectionComplete消息后，根据里面的信息，选定相应的MME，然后通过eNodeB和MME之间的S1-C接口发送InitialUEMessage给MME。
在此消息中，eNodeB将UE发送的NAS消息转发给MME（36。
413），除此之外，在此消息中，还包括如下项：
IE/GroupName
Presence
MessageType
M
eNBUES1APID
M
NAS-PDU
M
TAI
M
E-UTRANCGI
M
RRCEstablishmentcause
M
S-TMSI
O
CSGId
O
GUMMEI
O
CellAccessMode
O
其中eNBUES1APID值表示在此eNodeB中UE的S1接口。
MME侧将利用此标识来确定UE所对应的S1－C逻辑连接。
TAI值由PLMNIDentitity和TAC组成，唯一表示了UE的TrackingArea。
MME接收到InitialUEMessage后，进行网络和UE之间NAS层的安全认证过程。
（参见另外的文章）。
NAS层的安全认证成功后，MME会向HSS发送UpdateLocationRequest消息，向HSS更新自己的位置信息。
同时，MME向HSS请求用户的APN签约信息。
包括缺省的APN设置，每个APN对应的PDN类型，缺省的EPSBearer的QOS设置等。
此后，MME就可以与SGW，PGW进行信令交互，为缺省的EPSBearer建立用户面和控制面的GTPTunnel了（GTP隧道）。
对于每个PDN的连接，需要建立一个控制面的GTPTunnel（GTP－C），包括MME和SGW之间的S11接口和SGW和PGW之间的S5接口。
对于每个EPSBearer，需要建立一个用户面的GTPTunnel（GTP－U），包括eNodeB和SGW之间的S1－U接口和SGW和PGW之间的S5接口。
在LTE中，GTP－U使用的版本号为1，注册的UDP端口号为2152。
GTP－C使用的版本号为2，注册的UDP端口号为2123。
在GTP的头部中，有一个重要的字段，叫做隧道端点标识符（TEID），标识了对端的GTP-U或GTP-C协议中的隧道端点。
由GTP隧道的接收端分配本地TEID值，供GTP隧道的发起方使用。
通过GTP-C消息在隧道的两个端点间交换TEID（包含在FTEID内）值。
通过IP地址，端口号，以及TEID值就可以唯一确定一个GTP的隧道。
MME分配相应的缺省EPSBearerID（即EBI），构造S11接口（控制面）上GTP－CTunnel的MME端标识MMEF－TEID（注意，此信令中只有S11上的控制面TEID，而不包含S1-U的用户面FTEID，S1－U的控制面终结在eNodeB和SGW之间，eNodeB的FTEID-U在后面的ModifyBearerRequest消息中发送），向GW发送CreateSessionRequest消息。
在CreateSessionRequest中，主要包含如下一些主要内容
（1） 用户的身份标识，如IMSI，MSISDN,MEI,ULI（UserLocationInformation）等
（2） 用户接入网的一些信息，（E－UTRAN，UTRAN等）
（3） 服务网络的信息，包括MCC,MNC等。
（4） GTP－CTunnel的信息，包括MMEF－TEID
（5） S5/S8Interface的信息，包括协议类型（GTP－C），PDN的地址（包含在PDN F－TEID内）。
（另外一个可能的协议类型就是PMIPV6）。
（6） PDN的类型（IPV4，IPV6或者IPV4、IPV6），APN，
（7） 将要建立的DefaultEPSBearer的相关信息，包括EBI（EPSBearerID）,QoS，APN－AMBR等，以及用于切换时的IndicationHeader等。
CreateSessionRequest
Flags:
72
010.....=Version:
2
....1...=T:
1
MessageType:
CreateSessionRequest（32）
MessageLength:
201
TunnelEndpointIdentifier:
0（SGW的TEID值，由于此时并没有建立GTP－C，因而取值为零）
SequenceNumber:
7660
Spare:
45056
InternationalMobileSubscriberIdentity（IMSI）
。
。
。
RATType:
IEType:
RATType（82）
IELength:
1
000.....=CRflag:
0
....0000=Instance:
0
RATType:
EUTRAN（6）
FullyQualifiedTunnelEndpointIdentifier（F-TEID）:
IEType:
FullyQualifiedTunnelEndpointIdentifier（F-TEID）（87）
IELength:
9
000.....=CRflag:
0
....0000=Instance:
0
1.......=V4（True-IPV4addressfieldExists,False-Doesn'tExistinF-TEID）:
True
.0......=V6（True-IPV6addressfieldExists,False-Doesn'tExistinF-TEID）:
False
...01010=InterfaceType:
S11MMEGTP-Cinterface（10）
TEID/GREKey:
3300033（TEID值是由接收端分配而由发送端使用）
F-TEIDIPv4:
30.0.1.1（30.0.1.1）
FullyQualifiedTunnelEndpointIdentifier（F-TEID）:
IEType:
FullyQualifiedTunnelEndpointIdentifier（F-TEID）（87）
IELength:
9
000.....=CRflag:
0
....0001=Instance:
1
1.......=V4（True-IPV4addressfieldExists,False-Doesn'tExistinF-TEID）:
True
.0......=V6（True-IPV6addressfieldExists,False-Doesn'tExistinF-TEID）:
False
...00111=InterfaceType:
S5/S8PGWGTP-Cinterface（7）
TEID/GREKey:
0
F-TEIDIPv4:
20.0.0.1（20.0.0.1）
PDNType:
IEType:
PDNType（99）
IELength:
1
000.....=CRflag:
0
....0000=Instance:
0
.....001=PDNType:
IPv4
（1）
SelectionMode:
IEType:
SelectionMode（128）
IELength:
1
000.....=CRflag:
0
....0000=Instance:
0
......00=SelectionMode:
MSornetworkprovidedAPN,subscribedverified（0）
PDNAddressAllocation（PAA）:
IEType:
PDNAddressAllocation（PAA）（79）
IELength:
5
000.....=CRflag:
0
....0000=Instance:
0
.....001=PDNType:
IPv4
（1）
PDNIPv4:
0.0.0.0（0.0.0.0）表示需要PGW分配IPV4Address
Indication:
IEType:
Indication（77）
IELength:
2
000.....=CRflag:
0
....0000=Instance:
0
0.......=DAF（DualAddressBearerFlag）:
False
.0......=DTF（DirectTunnelFlag）:
False
..0.....=HI（HandoverIndication）:
False
...0....=DFI（DirectForwardingIndication）:
False
....0...=OI（OperationIndication）:
False
.....0..=ISRSI（IdlemodeSignallingReductionSupportedIndication）:
False
......0.=ISRAI（IdlemodeSignallingReductionActivationIndication）:
False
.......0=SGWCI（SGWChangeIndication）:
False
....0...=PT（ProtocolType）:
False
.....0..=TDI（TeardownIndication）:
F
升级会员 