received attach aept! gprs registration suessful
“gprs附着成功！”小高报告，声音稳定。这在意料之中。
第二步：pdp上下文激活。获取ip地址，打通数据通道。
[s] sendg activate pdp ntext reest (apn=testapn) [llc] sendg ui fra 网络模拟器进行ip地址分配和路由建立。 [s] received activate pdp ntext aept! ip address=100110 assigned
“pdp激活成功！ip地址获取成功！”
到目前为止，一切顺利。但真正的考验在于数据传输的稳定性和持续性。
第三步：连续pg包测试。验证基本的ip连通性和网络延迟。
工程师在连接芯片调试串口的终端上输入命令： pg -t 8888 （持续向模拟的互联网服务器地址发送pg包）
[ip stack] sendg ip echo reest (seq=1) reply received! rtt=150s [ip stack] sendg ip echo reest (seq=2) reply received! rtt=148s [ip stack] sendg ip echo reest (seq=3) reply received! rtt=152s ……
pg包如同欢快的音符，在屏幕上持续不断地跳动着，每一个都得到了及时的回应，往返时延（rtt）也稳定在一个合理的范围内（考虑到gprs的延迟特性）。
“连续pg测试稳定！未出现丢包或超时！”工程师兴奋地报告。
这意味着基本的ip数据链路是稳定可靠的！实验室里响起了一阵压抑的掌声！
但这还不够！pg包只是小数据量的测试。真正考验gprs性能的，是持续的数据下载。
第四步：小文件ftp下载测试。模拟用户下载铃声、图片或早期网页等场景。