乾隆湖3站终端无法上网问题分析

1、乾隆湖3站终端无法上网问题分析一、问题现象： 在淮北日常单站验证过程中，发现在一个4G站点下（HB-濉溪-乾隆湖3站-HFTA-912365-23），终端开机注册后，无法进行数据业务。二、问题分析：2.1、收集CDL日志进行分析：通过收集CDL日志进行分析，可以看到在终端开机后完成RRC连接、鉴权和安全模式控制后，EPC下发initial context setup request请求建立默认EPS承载，但基站返回failure消息，如下图所示：2.2、失败消息查看：从基站返回的失败消息看，携带原因值为 transport-resources-unavailable,传输资源不可用，此原因大多情况均与SGW的路由有关；2.3、查看initial context setup request查看initial context setup request消息中携带传输IP地址如下： 可以确认由于与对端业务传输IP地址协商不一致导致默认EPS承载建立失败，终端无法附着，不能进行业务。三、SCTP 基本信令流程3.1、 偶联的建立和发送流程：SCTP 端点A 启动建立偶联，并向端点B 发送一个用

2、户消息，随后端点B 向A 发送 两个用户消息。（假定这些消息没有捆绑和分段）。信令流程如图1所示。图1 偶联建立过程消息交互图(1) 端点A 创建一个数据结构TCB（传输控制块）来描述即将发起的这个偶联（包 含偶联的基本信息），然后向端点B 发送INIT 数据块。INIT 数据块中主要包 括如下参数：启动标签（Initiate Tag）：对端验证标签，如设为Tag_A。Tag_A 是从1 到 4294967295 中的一个随机数。输出流数量（OS）：本端点期望的最大出局流的数量。输入流数量（MIS）：本端点允许入局流的最大数量。(2) 端点B 收到INIT 消息后，立即用INIT ACK 数据块响应。INIT ACK 数据块中 必须带有如下参数：目的地 IP 地址：设置成INIT 数据块的起源IP 地址。启动标签（Initiate Tag）：设置成Tag_B。状态 COOKIE（STATE COOKIE）：根据偶联的基本信息生成一个TCB，不 过这个TCB 是一个临时TCB。这个TCB 生成以后，将其中的必要信息（包含 一个COOKIE 生成的时间戳、COOKIE 的生命期）和一个本端

3、的密钥通过 RFC2401 描述的算法计算成一个32 位的摘要MAC（这种计算是不可逆的）。 必要信息和MAC 组合成STATE COOKIE 参数。本端点传送地址、大入局流的数量和最大出局流的数量。(3) 端点A 收到INIT ACK 后，首先停止INIT定时器离开COOKIE-WAIT 状态， 然后发送COOKIE ECHO 数据块，将收到INIT ACK 数据块中的STATE COOKIE 参数原封带回。最后端点A 启动COOKIE定时器并进入 COOKIE-ECHOED 状态。(4) 端点B收到COOKIE ECHO数据块后，进行COOKIE验证。将STATE COOKIE 中的TCB 部分和本端密钥根据RFC2401 的MAC 算法进行计算，得出的MAC 和STATE COOKIE 中携带的MAC 进行比较。如果不同则丢弃这个消息；如 果相同，则取出TCB 部分的时间戳，和当前时间比较，看时间是否已经超过 了COOKIE 的生命期。如果是，同样丢弃。否则根据TCB 中的信息建立一个 和端A 的偶联。端点B 将状态迁入ESTABLISHED，并发出COOKIE ACK 数 据块

4、。端点B 向SCTP 用户发送SCOMMUNCIATION UP 通知。(5) 端点A 向端点B 发送一个DATA 数据块，启动T3-RTS 定时器。DATA 数据 块中必须带有如下参数：TSN：DATA 数据块的初始TSN。流标识符（Stream Identifier）：用户数据属于的流，假设流标识符为0。流顺序码（Stream Sequence Number）：所在流中的用户数据的顺序号码。 该字段从0 到65535。用户数据（User Data）：携带用户数据净荷。(6) 端点B 收到DATA 数据块后，返回SACK 数据块。SACK 数据块中必须带有 如下参数：累积证实 TSN 标签（Cumulative TSN Ack）：端点A 的初始TSN。间隔块（Gap Ack Block）：此值为0。 端点 A 收到SACK 数据块后，停止T3-RTX 定时器。(7) 端点B 向端点A 发送第一个DATA 数据块。DATA 数据块中必须带有如下参 数：TSN：端点B 发出DATA 数据块的初始TSN。流标识符（Stream Identifier）：用户数据属于的流，假设流标识符为0。流

5、顺序码（Stream Sequence Number）：所在流中的用户数据的顺序号码。 假设流顺序码为0。用户数据（User Data）：携带用户数据净荷。(8) 端点B 向端点A 发送第二个DATA 数据块。DATA 数据块中必须带有如下参 数：TSN：端点B 发出DATA 数据块的初始TSN1。流标识符（Stream Identifier）：用户数据属于的流，假设流标识符为0。流顺序码（Stream Sequence Number）：所在流中的用户数据的顺序号码。 此时流顺序码为1。用户数据（User Data）：携带用户数据净荷。(9) 端点A 收到DATA 数据块后，返回SACK 数据块。SACK 数据块中必须带有 如下参数：累积证实 TSN 标签（Cumulative TSN Ack）：端点B 的初始TSN。间隔块（Gap Ack Block）：此值为0。3.2、 偶联关闭流程：一个端点退出服务时，需要停止它的偶联。偶联的停止使用两种流程：偶联的中止 流程（非正常关闭）和偶联的正常关闭流程。 偶联的中止（非正常关闭）可以在任何未完成期间进行，偶联的两端都舍弃数据并 且不提交到

6、对端。此种方法不考虑数据的安全。偶联的中止步骤比较简单：发起端 点向对端端点发送ABORT 数据块，发送的SCTP 分组中必须填上对端端点的验证 标签，而且不在ABORT 数据块中捆绑任何DATA 数据；接收端点收到ABORT 数 据块后，进行验证标签的检查。如果验证标签与本端验证标签相同，接收端点从记 录上清除该偶联，并向SCTP 用户报告偶联的停止。偶联的正常关闭：任何一个端点执行正常关闭程序时，偶联的两端将停止接受从其 SCTP 用户发来的新数据，并且在发送或接收到SHUTDOWN 数据块时，把分组中 的数据递交给SCTP 用户。偶联的关闭可以保证所有两端的未发送、发送未证实数 据得到发送和证实后再终止偶联。图2 偶联正常关闭消息交互图偶联的正常关闭步骤如下：(1) 偶联关闭发起端点A 的SCTP 用户向SCTP 发送请求SHUTDOWN 原因。 SCTP 偶联从ESTABLISHED 状态迁入SHUTDOWN-PENDING 状态。在这 个状态，SCTP 不接受SCTP 用户在这个偶联上的任何数据发送请求。同时等待端点A 所有发送未证实的数据得到端点B 的证实。当所有端点A 发

7、送未证 实数据得到证实，则向端点B 发送SHUTDOWN 数据块。端点A 启动 T2-shutdown 定时器进入SHUTDOWN-SENT 状态。启动T2-shutdown 定时 器的目的是等待端点B 发回的SHUTDOWN-ACK 数据块，如果定时器超时， 则端点A 必须重新发送SHUTDOWN 数据块。(2) 端点B 收到SHUTDOWN 消息后，进入SHOUTDOWNRECEIVED 状态， 不再接收从SCTP 用户发来的的新数据，并且检查数据块的累积TSN ACK 字 段，验证所有未完成的DATA 数据块已经被SHUTDOWN 的发送方接收。当 端点B 所有未发送数据和发送未证实数据得到发送和证实后， 发送 SHUTDOWN ACK 数据块并启动本端T2-SHUTDOWN 定时器，并且进入 SHUTDOWN-ACK-SENT 状态。如果定时器超时了，端点B 则重新发送 SHUTDOWN ACK 数据块。(3) 端点A 收到SHUTDOWN ACK 消息后，停止T2-shutdown 定时器，并且向端 点B 发送SHUTDOWN COMPLETE 数据块，并清除偶联的所有记录。端点B 收到SHUTDOWN COMPLETE 数据块后， 验证是否处于 SHUTDOWN-ACK-SENT 状态。如果不是处于该状态，则丢弃该数据块；如 果端点处于SHUTDOWN-ACK-SENT 状态，端点B 则停止T2-shutdown 定时 器并清除偶联的所有记录，进入CLOSED 状态。四、解决措施4.1、对基站状态和SCTP链路核查：小区状态为“正常”，SCTP链路状态为“与对端建立成功”；4.2、核查路由关系：基站侧已经配置了乾隆湖机房MME1 MME2 SGW地址均已经配置：4.3、添加一条路由关系：添加一条路由关系，指向濉溪县局SGW地址，添加后终端附着正常，可以进行业务：4.4、现场复测核查：调整后现场复测正常，数据业务正常，可以进行业务：五、总结经验：1、开机附着流程中，基站侧的路由指向和EPC下发的地址需协商一直，因此在制作基站数据时到SGW的路由关系需添加完整；2、对于SCTP 基本信令流程烂熟于心，偶联的建立和发送流程和偶联关闭流程要重点掌握，在遇到类似的问题之后便可迎刃而解。

《乾隆湖3站终端无法上网问题分析》由会员d****0分享，可在线阅读，更多相关《乾隆湖3站终端无法上网问题分析》请在金锄头文库上搜索。