LTE attach流程及apn作用

本文深入解析LTE网络附着流程,重点分析initialAttach消息,包括AttachReq与PDNconnectivityReq的结合,探讨defaultBearer建立机制及网络侧对APN的决定。同时,文章详细阐述了NAS安全保护下消息的编码格式,以及EMM层如何为ESM提供消息路由服务。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

在通过AT+CGDCONT=1,"IP","ctnet"设置pdp时发现,无论apn设置成什么,都可正常激活网络,并进行拨号上网,

 现分析LTE网络附着流程,具体的消息流过程还是按照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呢,直接被包含在第一层不行么?)

 

<think>好的,我现在需要帮助用户了解如何解析LTE-M报文。首先,我得确认用户提到的LTE-M是什么。LTE-M通常指的是LTE-Machine Type Communication,属于物联网中的一种通信技术,基于LTE网络优化,适用于低功耗、广覆盖的设备。用户想知道如何解析其报文,可能涉及通信协议的数据解析。 接下来,我需要考虑LTE-M的协议栈结构。LTE-M属于蜂窝物联网,其协议栈应该包括物理层、MAC层、RLC层、PDCP层、RRC层以及应用层。用户可能关注的是高层协议如NAS(非接入层)或APN(接入点名称)相关的报文,或者应用层的数据解析。 然后,解析报文通常需要了解协议的具体格式。例如,在LTE-M中,用户数据最终会封装在IP包中,可能通过CoAP、MQTT等应用层协议传输。如果是解析应用层的数据,可能需要先解封装底层协议,如PDCP、GTP-U等。 用户可能缺乏对协议分层的了解,需要分步骤解释。我应该先介绍整体流程,再具体到每一层的解析方法。例如,从物理层到应用层的数据处理过程,可能需要使用抓包工具如Wireshark,配合相应的协议分析插件。 另外,需要考虑加密问题。LTE-M的数据在传输过程中可能加密,尤其是用户面数据。如果用户没有解密密钥,可能无法解析有效载荷部分。需要提醒用户注意这一点,可能需要联系运营商或设备厂商获取密钥。 还需要提到具体的工具和示例。例如,使用Wireshark捕获空口信号或核心网接口的数据包,过滤出LTE-M相关的信令或用户面数据。例如,在NAS层解析Attach Request或Service Request消息,查看其中的参数如IMSI、IMEI等。 可能用户的实际需求是调试物联网设备,检查通信问题。因此,解析报文可以帮助诊断连接失败、数据传输错误等。需要建议用户结合具体场景,分析特定消息的内容,比如RRC连接建立、承载激活、数据传输等阶段。 最后,总结解析步骤,强调协议文档的重要性,以及实际操作中的注意事项,比如加密处理、工具配置等。确保回答结构清晰,逐步引导用户理解和实施解析过程。</think>解析LTE-M报文需结合蜂窝通信协议栈分层处理,以下是关键步骤和要点: --- ### 一、理解LTE-M协议栈分层 LTE-M报文封装遵循蜂窝物联网协议分层结构: $$ \text{应用层数据} \rightarrow \text{TCP/UDP} \rightarrow \text{IP} \rightarrow \text{PDCP} \rightarrow \text{RLC} \rightarrow \text{MAC} \rightarrow \text{物理层} $$ --- ### 二、解析工具准备 1. **抓包工具** - 空口抓包:使用专业设备(如Keysight X系列仪表)捕获无线信号。 - 核心网抓包:通过Wireshark监听S1-U(eNodeB到核心网)或NBIoT接口。 2. **协议分析插件** 加载3GPP TS 36.xxx系列协议解码器(如Wireshark的LTE、NAS-EPS插件)。 --- ### 三、分层解析示例(以下行内公式表示字段含义) 1. **物理层解析** - 提取时频资源块,例如:$RB_{\text{分配}} = 6$ 表示占用6个资源块。 2. **MAC层解析** - 解析调度信息,例如:$MCS=10$(调制编码方案)、$HARQ\_ID=3$。 3. **RRC层关键消息** ```plaintext RRCConnectionSetupComplete ├─ ue-CapabilityRequest // UE能力查询 └─ selectedPLMN-Identity: 1 // 选择的运营商ID ``` 4. **NAS层核心信令** ```plaintext AttachRequest ├─ IMSI: 460011234567890 // 用户身份标识 ├─ UE-NetworkCapability // 支持的加密算法 └─ PDN-Type: IPv4v6 // 请求的IP类型 ``` --- ### 四、用户面数据解析 1. **PDCP层处理** - 解密:使用$K_{UPenc}$密钥解密用户面数据(需运营商支持) - 校验完整性:通过$MAC-I$字段验证 2. **IP数据解析** 解封装后获得典型物联网协议: ```plaintext IPv6 Header └─ CoAP Payload ├─ URI-Path: /temp // 温度传感器数据 └─ Payload: 25.6℃ // 实际测量值 ``` --- ### 五、特殊场景处理 1. **PSM省电模式** 解析`TAU(Request)`消息中的: $$ T_{Active} = 10s,\quad T_{Periodic} = 1h $$ 表示设备激活周期配置。 2. **eDRX扩展DRX** 在`RRCConnectionReconfiguration`中解析: $$ eDRX\_Cycle=10.24s,\quad PTW=2s $$ --- ### 六、调试建议 1. **典型故障排查** - 连接失败:检查`RRCRejectCause`或`NAS-EMM Cause` - 数据传输异常:检查PDCP序列号$SN_{\text{COUNT}}$连续性 2. **参考文档** - 3GPP TS 36.331(RRC协议) - 3GPP TS 24.301(NAS协议) --- 通过分层解析并结合具体业务场景,可有效分析LTE-M设备通信行为。实际操作中需注意运营商特定的参数配置及加密策略。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值