1.IP老化问题
在项目中，存在设备端订阅后，通过app下发数据失败的问题，问题定位：IP会出现老化（通信的IP和端口发生变化）。由于UDP 通信方式，终端通过核心网EPC 与其他公网的服务器通信 时，EPC 会将内网的IP 映射成一个外网的IP 加端口，这一映射关系存在老化机制。实际测试发现：如果成功入网的设备超过2 分钟不与公网服务器进行数据交互，则上次通信的IP 及端 口映射关系失效，此时即便终端处于eDRX 甚至DRX 工作模式，公网的服务器无法通过上次 成功通信的IP 及端口与终端进行通信，除非终端重新上报数据。
1.1通信流程：
1.1.1 dss驻网成功获得运营商内网IP10.xx.xx.xx1.1.2 上发信息（上报）：
1.1.2.1设备上发信息，运营商会将内网IP映射成一个外网IP 110.xx.xx.xx
1.1.2.2服务器接收信息，服务器接收到外网IP发送来的数据
1.1.3 下发信息（订阅+下发）：
1.1.3.1 设备上发信息，运营商会将内网IP映射成一个外网IP 10.xx.xx.xx
1.1.3.2 服务器接收订阅，记录当前通信的外网IP110.xx.xx.xx 注意此IP的存在时间是有限的（中国移动为2min）
1.1.3.3 服务器接收app推送到消息，向记录的外网IP110.xx.xx.xx发送数据。
1.2 IP老化：在执行1.1.3.3时，可能存在IP老化（IP有效性有时限）的问题。当IP老化后，服务器无法找到，设备订阅的IP地址，导致通信失败
2.解决方案NAT在解决IPv4地址短缺问题上，并非没有副作用，其实存在很多问题。
首先，NAT使IP会话的保持时效变短。因为一个会话建立后会在NAT设备上建立一个关联表，在会话静默的这段时间，NAT网关会进行老化操作。这是任何一个NAT网关必须做的事情，因为IP和端口资源有限，通信的需求无限，所以必须在会话结束后回收资源。通常TCP会话通过协商的方式主动关闭连接，NAT网关可以跟踪这些报文，但总是存在例外的情况，要依赖自己的定时器去回收资源。而基于UDP的通信协议很难确定何时通信结束，所以NAT网关主要依赖超时机制回收外部端口。通过定时器老化回收会带来一个问题，如果应用需要维持连接的时间大于NAT网关的设置，通信就会意外中断。因为网关回收相关转换表资源以后，新的数据到达时就找不到相关的转换信息，必须建立新的连接。当这个新数据是由公网侧向私网侧发送时，就会发生无法触发新连接建立，也不能通知到私网侧的主机去重建连接的情况。这时候通信就会中断，不能自动恢复。即使新数据是从私网侧发向公网侧，因为重建的会话表往往使用不同于之前的公网IP和端口地址，公网侧主机也无法对应到之前的通信上，导致用户可感知的连接中断。NAT网关要把回收空闲连接的时间设置到不发生持续的资源流失，又维持大部分连接不被意外中断，是一件比较有难度的事情。在NAT已经普及化的时代，很多应用协议的设计者已经考虑到了这种情况，所以一般会设置一个连接保活的机制，即在一段时间没有数据需要发送时，主动发送一个NAT能感知到而又没有实际数据的保活消息，这么做的主要目的就是重置NAT的会话定时器。
2.1 心跳保活通过周期性的发生心跳数据包，保持ip使用状态即可
2.2 部署电信平台 设备与服务器之间的通信由电信平台调度完成（之前的知识由运营商基站转发），步骤如下：
1)设备订阅电信平台
2)电信平台与服务器进行绑定
3)当服务器需要发起下发时，先下发到电信平台，其次再到设备端
