LTE attach 过程的某些过程和具体消息

js99182002

  

具体的消息流过程还是按照3GPP 23.401。针对attach过程的某些流程和具体消息展开说明。并给出相对应的规范出处。

1. 首先第一条initial Attach 消息： 从具体的wireshark的包来看， 这个intial attach包含了两个事件， attach Req+PDN connectivity Req

    一个是EMM 层面的消息，一个是ESM 层面的消息。

    Attach Req 无需多讲，这是终端登陆网络侧所必须的过程。而PDN Conncetivity Req的出现是为了建立default Bearer。

   在NAS 规范24.301 6.5.1.1 中就是很明确的提出在attach req中所包含的PDN Con Req 是为了最初的default bearer建立所发（这个独立于可能还会和其他APN 所建立的default bearer），在这个PDN Connect Req里UE 侧不需要提交APN的地址，换句话讲， 这个initial default bearer所连向的APN 应该由网络侧来决定。终端只提供了UE 所支撑的IP地址类型。

   （但是也有例外，虽然规范里要求是这样，但是也有观点认为，UE提供了APN 更有利于UE 对业务需求，例如UE想直接连入企业网，那得需要UE 提供APN，但是这个APN的提供得在鉴权和NAS安全关联建立之后，因为default APN的提供应该估计应该根据实际运营商的业务实现或者客户需求来做）

      When the PDN CONNECTIVITY REQUEST message is sent together with an ATTACH REQUEST message, the UE

shall not include the APN.

    而把PDN Connectivity Req和Attach Req绑定的考虑出自于 3GPP2 24.301, 4.2节，LTE 中实现了the ip of UE alwanys online的想法。

a. 具体来看这个消息体。在这条消息中，在S1AP 层面上，暂时还只有eNB-UE-S1AP-ID的value，网络侧的S1AP 的 ID 需要等MME 来回复。

b. 在NAS 层（如图2所示）：其中 EPS mobility message 的地方出现了两次。 ESM PDN Connet Req的消息被包含在EMM 消息中，通过ESM Message container这个IE ，EMM 包含了ESM的内容。

   EPS Mobility Message 出现两次的原因是: 这条消息采取了24.301中 9.1 节 所列出的消息编码格式----- a security protected NAS message. 如图3 所示：

  随后具体到每条NAS 的Message， NAS message 本身又有Protocol discriminator 和 Security header type 的IEI. 所以造成 EPS Mobility managerment message 这个header出现了两次的情况。 （但是为什么要出现两次呢？ NAS 具体的Message 的Security header不够么？ 为什么还要再加一层Security header上去呢?)

  那么如果UE 侧已经有一个valid NAS security context  存在了，那么UE 需要在attach Req 中置上intergrity protect。 对应于3GPP 24301:

1) Except for the case described in item 3 below, the UE shall transmit the initial NAS message integrity protected with the current EPS security context, but unciphered. The UE shall include the eKSI indicating the current EPS security context value in the initial NAS message. The MME shall check whether the eKSI included in the initial

NAS message belongs to an EPS security context available in the MME, and shall verify the MAC of the NAS message. If the verification is successful, the MME may re-establish the secure exchange of NAS messages:

- by replying with a NAS message that is integrity protected and ciphered using the current EPS security context. From this time onward, all NAS messages exchanged between the UE and the MME are sent integrity protected and except for the messages specified in subclause 4.4.5, all NAS messages exchanged between the UE and the MME are sent ciphered; or

- by initiating a security mode control procedure. This can be used by the MME to take a non-current EPS security context into use or to modify the current EPS security context by selecting new NAS security algorithms;

而一个Scurity Context 是通过NAS COUNT 来标示的。 NAS Count对应于NAS Header呢，就是Sequence Number。 MME 通过Sequence Number来找到相对应的Security Context （如果存在的话）， 然后再使用 Message Authentication Code来完成检查.

                                   图3

c. 随后再打开 ESM Message Container 这个IEI。

   可以看到：

在这段消息体内，值得注意的是这几个header： EPS bearer identity ， Procedure transaction id。

copy from 24.007：

The EPS bearer identity is used to identify a message flow。 这个 NAS 中的EPS bearer id 和随后在GTP-C 上建立的Bearer Context ID 相互对应。

Procedure transaction：  A L3 protocol may define that the second octet of a standard L3 message of the protocol contains the proceduretransaction identity (PTI). The PTI allows distinguishing up to 254 different bi-directional messages flows for a given PD and a given SAP. Such a message flow is called a transaction. The procedure transaction identity is released when the procedure is completed.

对于这两个heder在LTE 中的运用，24.301 又给出了详细的描述。 参看 6.3.2.

并且通过24.007 中的routing model来看， PTI+PD 是EMM 用来routing消息给ESM 的。 而一旦bearer context 建立完，ESM 能够分配出context id后，后续的消息就不需要PTI了。

例如： PDN Context Req （from UE to MME)  中需要有PTI， EPS default Bearer req （from MME to UE) 需要有（PTI,EBI) , 随后的 EPS default bearer Resp （from UE to MME)只需要有EBI了，就不需要PTI了。

  在这个过程中，EMM层需要为ESM 提供一个routing服务，EMM 通过PTI来区分向ESM 建立不同的transcription， MME 收到req之后，回出的 Default Bearer Req 中，也需要PTI，是因为它需要向UE 标明 它是为了之前那条ESM transaction分配了EBI， UE 收到之后，双方在ESM 上达成了统一，就不需要PTI的配合了，因为Bearer ID 的唯一性就足够EMM 在随后的过程中，将ESM的消息路由给相对应的EMS layer来处理。

   这个default Beraer的的建立在MME 被pending在那边，因为要完成EMM的过程之后， MME 才会去处理ESM 的状态机。NAS 的PTI,EBI的再次出现要等到MME-SGW-PGW之间的bearer context 建立完成后。

2） 随后New MME 向 UE 要求获取IMSI， MME 可以根据IMSI 向 HSS 要求鉴权数据以及随后的用户数据。但这个时候因为security mode还未建立，所以NAS 层面的消息是

Plain NAS message， not security protected， 应该也算危险的地方。

3） MME 收到IMSI 之后，和HSS 通过diameter 的AIR/AIA 完成鉴权五元组的交互。

4） MME 向UE 发送 RAND ,AUTN value， 要求UE上报鉴权数据。

5） MME 收到 NAS Authentication Resp，鉴权通过之后， 开始security mode 的建立。

      按照 24.301 中4.4.2.4 的规定，

      The SECURITY MODE COMMAND message sent by the MME includes the eKSI of the new EPS security context to be used. The MME shall send the SECURITY MODE COMMAND message integrity protected with the new EPS security context, but unciphered. When the UE responds with a SECURITY MODE COMPLETE, it shall send the message integrity protected and ciphered with the new EPS security context.

     MME 下发的Security Command 只是integrity protected and unciphered. 但是UE 随后的Security Complete 消息应该是被cipher过的。

      但是如果MME 对于cipher的规则选择的是“ null ciphering alogrithm“ EEA0， 虽然随后UE 和MME 之间的NAS 没有经过cipher，但是在security header也必须置上ciphered。

     （参见24.301 - 4.4.5， ” If the "null ciphering algorithm" EEA0 has been selected as a ciphering algorithm, the NAS messages with the security header indicating ciphering are regarded as ciphered”)

      具体见图：（还是不理解为啥要插两层EMM 的 Security header 进去， 第一层的Security header 可以理解， 但是第二层对于具体的EMM ，为啥还需要一个security header呢，直接被包含在第一层不行么？）

6)  接下来就是MME 得去HSS 取数据了。使用DIAMETER ULR/ULA..   

     再分个子节吧。。。感觉这部分用户很重要。没有完全看过这部分的用户数据。

ULR 没什么大的描述。着重对ULA 解析下。规范参照3gpp 29272, 23401

对于ULA的AVPs来讲，最关心的用户数据都在Subscription-Data中，

from 23401.5.3.2.1 step 11:

The Subscription Data contain one or more PDN subscription contexts. Each PDN subscription context contains an 'EPS subscribed QoS profile' and the subscribed APN-AMBR (see clause 4.7.3).

如下图：在APN-Configuration-Profile下有个Context-ID AVP， 给出了 value=2， 那意思就是在随后的几个APN-Configuraions group中选定了 Context 为2 的APN 作为default APN 进行附着。

随后点开Context-Identifier 为2 的APN-Configuraion 的AVP 看下：

Service-Selection AVP:

This IE shall contain the APN for the selected and dynamically allocated PDN GW. It shall be present if the selected PDN-GW is present and is particular for one specific APN and not common to all the APNs. 这个也呼应了HSS对于default Bearer提供的APN 不能是Wild type APN。

并且这个value是APN的Network Identifier, 于随后的Operation Identifier构成完成的APN，用来做NAPTR/AAA查询去获得PGW地址。

对于随后的QOS-Profile理解不好。 QCI 还好理解，但是对Allocation-Retention-Priority 还未理解发生场景。

The VPLMN Dynamic Address Allowed AVP is of type Enumerated. It shall indicate whether for this APN, the UE is allowed to use the PDN GW in the domain of the HPLMN only, or additionally, the PDN GW in the domain of the VPLMN.. If this AVP is not present, this means that the UE is not allowed to use PDN GWs in the domain of the VPLMN.

这段对于后面的PGW选择有关联么？还是VPLMN 的PGW 会去连接 HPLMN的 PGW？

（另外从现场的pcpa来看，如果手机在附着时候请求的APN不是HSS的签约数据中的default APN 地址，那MME 会遵循UE 的APN 去建立 default Bearer ,而不使用HSS中的签约数据）

可见规范写规范的。。。实际用实际的。。）

那么正常情况下，MME还是应该使用default APN-Configuraion-Profile为UE建立 default Bearer 链接。MME 通过用DNS query 针对PGW selection 完成后，就开始建立tunnel的过程。

这段开始描述 MME, SGW, PGW 之间建立Tunnel 的过程。主要使用Create Session Req/Resp for default Bearer 和 Create Bearer Request/Resp for dedicated Bearer setup.

so, 1st one is MME send to SGW the Create Session Req, the message sample is :

1. The tunnel Endpoiint Identifier value is 0 , as the C-TEID for Uplink doesn't assign by the SGW.

2. PDN TYPE is : IPV6 , ask the PGW to assign the ipv6 for the UE.

The more important things are t he  Fully Qualified Tunnel Endporint Identifier (F-TEID), PCO, and the Bearer Context.

There are two F-TEIDs, One is the Control Plane of MME  with IP address , another one is for the PGW.( Which is selected by the MME accroding to the APN name by DNS).

SGW will do the Create Session REQ/RESP towards the IP of PGW. so that the TEID is "0" for the PGW, Need to wait  the PGW to assign the value.

About the PCO (Ptorocol Configuration Options )

here is a answer that :http://lteuniversity.com/ask_the_expert/f/59/t/2422.aspx

The purpose of the Protocol Configuration Options (PCO) is to provide additional optional information about the destination network that the UE is connecting to. For example, when a UE connects to the Internet it will be given an IP address and it will be given a PCO that includes the default gateway IP address, the DNS server address, etc. All of these additional pieces of information are given in the PCO.

Give to examples:

for the IMS accsss, the UE need to get the PCSCF address.

for the internet access, the UE need to get the DNS service ip address.

the first one , the "IP address allocation via NAS signalling" ,  i think that the UE ip will get be LTE, don't the use the DHCP to get from the external network.

for the Bearer Context:  MME only assign a EBI, others value need the PGW to assign ( by the Policy and Charging rule from PCRF)

2nd one is the Create Session Req from SGW to PGW, most of message header and value are same as the 1st one sent from MME to SGW.

Except:  The TEID AND IP for Control Plane are changed to SGW,

               And in the Bearer Context: there is the TEID and IP of SGW towards PGW for User-Plane.

到这个地步，MME 和SGW 已经给出了下行信令面通道会使用到的TEID 和IP，并且SGW 也给出了下行通道会使用到的用户面的TEID和IP。

随后PGW 就会分配相应的QOS，信令面和用户面，但是这个qos 和charging rule 也收到PCRF 的控制。。。。扔到第4节描述下PCRF的流程，再回来写PGW的。

继续上次， MME,SGW 已经开始建立tunnel。 现在轮到PGW了。 在发送Create Session Response的时候，PGW 需要向PGW 请求用户数据。

规范3gpp 23203, 3gpp 29210, 3gpp 29212.

根据 23203 里的架构， PGW (PCEF) 向 PCRF 请求用户有关Policy 和Charing rule的数据。（这里特指用Dynamic rule; predefined rules则是在PGW上预先定义好了，不需要使用GXinterface）。

AF 因为没有相应的pcap流程对应，在这不进行描述。

The Policy and charging control rule (PCC rule) comprises the information that is required to enable the user plane detection of, the policy control and proper charging for a service data flow. The packets detected by applying the service data flow template of a PCC rule are designated a service data flow.

至于那些informations 在PCEF 和PCRF 中传递， 在23.203 58页已经列出。

只看在CCR 消息中的AVPs：

CCR 中的 Default-EPS-Bearer-QoS ：

When this AVP is sent from the PCEF to the PCRF, it indicates the subscribed QoS for the default EPS bearer and/or the retained QoS for the default EPS bearer in the PCEF. When this AVP is sent from the PCRF to the PCEF, it indicates the authorized QoS for the default EPS bearer.

CCA消息：

关心的AVP header 是 Charing-Rule-Install, Qos-Inforamtion, Default-EPS-Bearer-Qos:

大家所关心的QOS， TFT 和Charging Rule 内容都在Charging-Rule-Install 这个AVP 里装着。点开这个AVP可以看到：

其中有两个Charing Rule，分别有不同的Rule-Name，并且将计费方式也给出了（Enable-offline), Flow-Description 也给出了上下行通道的过滤端口值，去生成TFT。

第一个Charing-Rule是给IMS 信令通道用的。第二个charging-Rule是给 其他IP 数据 用的。在QOS-Information AVP 中，可以看到具体的QCI， 和MRB-UL/DL. 但是优先级上IMS高于Default Bearer。。。意思， 虽然Default Bearer 维持着 IP 地址，但是在具体的用户面的数据包，IMS 数据应该优于 其他的IP 数据

因为从另外的AVP: Default-EPS-Bearer-QOS中看出，这个AVP给出了Default Bearer用的QCI，当时这个QCI可以和之前 Charing-Rule-Install里的QCI一致，但是意义不同。

1，.Default-Bearer所需的QOS，OCI也算是Charing-RULE 里的一个用户profile，当然也应该被包含于Charging-Rule中。

2.  针对Default-Bearer，也会有其他的IP 包，那么这部分的计费信息和要求也会被包含于charging-rule中。

因次虽然Default-EPS-Bearer-Qos 看上去内容好像是从 Charing-Rule中部分copy出来，但是是具体标示了那个部分是用来做为Default Bearer。

至于Event-Trigger 就比较好理解。定义了在什么情况下，QOS会发生改变，需要双方再次协商。

总算这部分写好了。貌似应该画个图更好。