标签: gprs

曾经三年前，完成GSM/GPRS的物理层系统调试后，简短写过一篇博文。其中，关于物理层调试总结了三点：   1.时间的同步：下行同步是基础，上行同步，比特同步，帧同步到复帧同步时隙同步，睡眠的长时间同步，不同小区的时间同步等；   2.频率的同步：接收频率同步，发射频率同步，多普勒频移，温度的漂移等；   3.功率的调整：调整的步长，调整的速度，动态范围等。   到如今，在LTE的系统调试上又破费了一些功夫。细想想，物理层调试基本上还是这样三点。不过，我们需要一些系统的方法去对这三点存在的问题进行分析定位。   与信号发生器的调试。用信号发生器，例如安捷伦的，产生你所需要的系统的信号，周而复始，然后通过射频电缆跟目标板连接。这样调试，能基本调试通过下行链路的各个环节的算法正确，各个环节的通信正确，调度也是正确的。当然，这个环节，还可以确认每个算法在目标板上实际运行所需要的运算量以及占用的内存空间大小等等指标。 与信号分析仪的调试。跟上一个环节类似，但是是针对上行链路的调试。目标板周而复始生成指定参数的信号波形，信号分析仪接收并进行基本同步和解调的分析，确定信号的带宽和符号级的处理是否正确。及时这个步骤正确地看到星座图，并不能说明上行链路完全正确了。因为比特级的crc验证其实还未做。 与协议分析仪的调试。这个环节不仅仅是综合了上述两个环节，更多的是他对整个协议栈的流程也进行了初步验证。他可以让目标板跟协议分析仪连续工作就如同目标板连接进入了实际的网络一样。但他还是很有局限性。就如最前面所说的三点，时间，频率和功率，协议分析仪的冗余度都很大。所以，你的目标代码在这些地方的处理不合适的话，协议分析仪可能还是可以正常的工作的。于是，你可以看到很好的流程跑起来的结果，但并不证明你的代码可以用了。 于是可以开始进行现场调试了。这里，就是真正地通过无线的空间跟实际基站调试的过程了，在上述的几个跟仪器都已经调试等很好的条件下之后。困难出来了，mib可能收不到了，sib可能收不全了，prach可能上不去了，rar可能没反应了，哈~~~ 一步步都调过来了，ping还是不通…问题咋就这么多呢？ 好吧，同学们，这才是真正调试工作开始了。祝贺你，晋级成功，开始第二关了。 mib收不到是吧，那么还是可以用示波器，加在目标板的ADC的A端。看看当你目标代码开始进行扫频，调整AGC，开始计算mib的这个过程中，A端都是什么信号。忽大忽小，还是很大溢出，还是太小啥也没有？啥也没有，拜托检查一下频点是否设置对了。基站在2.6G，你在2.5G上使劲，那是没用的。忽大忽小，就是不合适，拜托检查AGC的调整过程，是否调整对了。接收的功率计算是否计算对了。功率大了，gain就往小了调，反之亦然，但是也别调过了。调过了，就振荡了，不是吗？信号大小合适了，那么根据你找到的主同步信号和辅同步信号，你需要进行接收时间窗的调试哟。别算错了，一定要让mib的信号能够按照你计算的时间点进入到你的接收窗口。如果没进来，这里可以dump出mib的数据波形来看看。一切都就绪了，那肯定能收到了。如果还收不到，那就没道理了，自己再想辙吧，就这些地方可能有问题。否则就是更加弱智的错误了。 sib的接收稍微讲究一点点。因为sib有调度周期。这些都是协议上规定好的内容。好好读协议，好好按照协议来实现就好了。理解的偏差就可能导致错误。且先收sib1，再收其他sib。协议这样规定，自有他的道理，你要不遵循规则，你调试起来就会比别人费劲一点点。为什么？其实都是血的教训。Sib1里告诉你基站的上下行配置，告诉你其他sib的调度周期，Sib1的调度是固定的帧号和子帧号。这就是答案了。 prach上不去吗？当然，前面sib都接受完全了，下行基本放心了。Prach是第一个上行，于是遇到问题太正常不过了。如果prach的波形数据本身，你通过算法验证阶段已经验证好了，通过信号分析仪阶段也已经对过星座图了，那么说明数据本身问题不大了。还是说加示波器看看吧。加在目标板的DAC的A端。眼睛瞪大大的，用两个探头同时抓取接收的信号和发射的信号来看哟！这样可以看到的信息比较多。首先prach的波形，是否直接跟你用matlab画出来看到的类似呢？要完全不像，那就奇怪了。你在目标板上跑程序是，程序发出的数据波形是matlab画的那段吗，地址是否搞错了？长得像的话，那就没问题了。幅度是不是太小了。这个是有可能的，数据本身幅度如果太小，要考虑基站收到时功率会太小而检测不到。幅度也合适，那么在基带数字域这个环节，还需要重点对比的就是接收的同步点和发射的同步点是否能对上了。如果同步点不对，那么prach会落到基站搜索窗的外面，基站是无法找到prach信号的。这个地方，查看波形，需要放大到很大，精确到us的级别。按照协议的规定来分析，发射的标准起点应该比接收的标准起点提前20us，那你看到的波形一定得是提前的，不能延后，哪怕1us，基站可能都收不到。看看，这些内容，最前面的三台仪器都是可以包容你的错误的，但是商用的基站是不会的。基站要考虑的是所有用户，大家都得按照协议来走，否则基站也没法工作了不是。 上行能通一个步骤，其他的步骤相对来说就好调多了。但你必须关注，功率，时间和频率这三个环节。不要一次调得太猛，调过了；也不要出现调整的很异常的值，例如时间只能往前调，不可能往后调，往后调就跟接收时隙混了，如果出现往后调，必定是程序出问题了。多看看数据和波形，后续的调试还有很多内容，整个系统能稳定可是不简单的事情。 今天先写到这里吧，后续内容待定……        

  对于Connectioin Reset的问题，困扰了好长时间，当逐步排除客户端出错的可能后，怀疑是服务端出现了问题。 最终由tcpdump和windump一起监视数据，发现了以前一直困扰着的connection reset问题的根本原因。 描述见：   而造成这个问题的原因是，当客户端直接退出而没有发送FIN，同时很快再次连接时，能够重新申请到新的连接，而旧的连接已经不存在。这个时候服务端一段时间检测不到旧连接的时候，会给就连接发送FIN命令来终止旧的连接。但是由于旧连接已经不存在，不会对服务端发送的FIN，进行回复，于是服务端在一段时间后，又发送了一个FIN。由于客户端还没有对服务端的FIN进行回复，服务端就要异常终止连接，这个时候对旧连接发送了一个Reset，然而奇怪的是，这个时候在服务端显示的是R发送给了旧连接，但是几乎就在同时，新建立的连接也收到了R，于是先建立的连接也被Reset了。 从windump显示的来看，R只发给了旧连接，新链接上在那一时刻没有数据交互。但是从tcpdump看到的结果是新连接也确实收到了R，如果服务端没有出错，客户端也没有出错，那么这个出错的地方，很可能就是使用的路由器了。 猜测是路由器再将转发Reset的时候，“顺便”也将Reset也发给了新链接。但是从一个Socket连接来讲，这个几乎不可能的。 莫非真的是路由器出错了？   注： 1、http://blog.csdn.net/tietao/article/details/8445646  Connection Reset By peer与Gprs

  GSM07.10：关于多路复用的协议 GSM07.07：GSM的GPRS AT指令集协议 GSM07.05：GSM的短信息和广播服务协议   1心跳功能 1.1 防止掉线。运营商为了防止终端挂在网上不传数据，在一定时间（一般为2分钟）内检测到有终端没有传输数据时，将会把终端踢下线。 1.2实现远程监控，可以知道终端的在线情况。 2、在线时间设置 目前应用中，一般使用40-60秒。   3、工作模式 3.1永远在线。则终端必须通过心跳，来维持，否则会因为（1.1）被踢下线。即需要一定的流量维持DTU在线。 3.2定时收发。1、中心呼叫方式：可以使用电路呼叫（即拨打电话），或者使用短信的方式，激活DTU上线。                     2、当终端需要发送数据时，DTU建立连接发送数据。   GPRS DTU:相当于MCU+Gprs Modem通过MCU控制Modem实现了，网络的永久在线。也实现了PPP连接，这里一般是MCU GPRS Modem:一般都是带有TCP/IP协议栈的，但是没有PPP协议即链路层协议。   http://company.mcuol.com/tjfelick/ProductDetail_76614.htm GTM900c的一些参数， http://wm.sim.com/product.aspx?id=1007 Simcom900a的一些参数   /*---------------------------------------------------------------------------------------------------------*/ 2012-12-12 GPRS（General Package Radio Service），通用分组业务。利用数据分组交换原理。当传送数据时，首先把数据打成一个个包，然后利用某个信道的一个时隙来传送数据。不传送不占信道，所以是按流量收费，而不是按占用信道的时间收费。 GPRS服务类型有CLASS A， CLASS B, CLASS C三种。A可以同时使用网络和电话功能；B在上网东风时候，会将电话功能屏蔽，当有电话进来时会自动奇幻网络；C则是单纯的网络应用，没有电话功能。 GPRS的速度有29种标准（即不同的上传和下载速度的组合），国内常用的是CLASS 8和CLASS 10两种，原理上为“4+1”和“4+2”，即4为下载速度为4倍的通道时槽速度，一条信道的速率为13.4kbps,理论速度为13.4*4=53.6Kbps，1和2是上传的速度，即CLASS 8 为13.4kbps。   GPRS缺点： 1、相对于无线专网成本不低，性价比优势不大；通信协议比专网复杂很多，入门有难度，不如无线专用简单易用。 2、受公网业务开通状况及i型您好覆盖范围的影响较大，能否在某处使用，完全取决于运行商的系统建设情况，不如无线专网灵活。 3、运行费用较高，GPRS按流量计费，通过网络的无用流量也会被计费。 4、实时性差，尤其是节假日系统的负荷，系统及网络阻塞严重，信息不畅，不能及时发送或者收到有用信息，会误事。 5、系统安全性较差，公网的安全性远不如专网。   GPRS可能出现的问题： 1、模块开机连接激战的时间长，要达到40秒左右。 2、天气不好时，连接GPRS时间长，大概要20秒作于，而且模块对命令回复正常，但是很多时候，服务器没有收到连接请求。 3、数据延迟，可能一段时间后，服务器才会收到之前GPRS模块发出的数据。造成模块判断失败。 解决的思路： 1、模块返回OK，说明命令成功到达模块且格式正确，并不表示连接基站收到数据处理了相应的任务。 2、由1，对于命令要判断OK之后的状态信息，对于没有状态信息的命令，就没有办法这样做。 3、应用层的心跳是必须的。用来判断是否还处于连接。   GPRS常见故障： 一、GPRS网络共享硬件故障： 1、信号强度低，措施：使用外置天线，馈线长1.5m。 2、电源功率余量小，措施：使用电流较大的电源，因为GPRS模块不拨号时工作电流为50ma，拨号时持续电流为200-1000ma，在留有余量的情况下，使用2A的电源适配器。 二、GPRS网络共享硬件故障： 1、不能连接，措施：需要重新连接，优势需要多次启动才能解决问题。GPRS网络是在无宽带连接的情况下的备用选择。因为，无线信号，共享服务稳定性，系统网络配置等都会影响其使用的稳定性。   GPRS网络共享白天或深夜一般比较正常。但是在通话高峰时段如（晚7：00-10:00）卡的现象较严重，因为在这些时段，移动基站的容量有限，且话音业务优先分配，当话务量接近饱和时GPRS的物理信道（时隙）分配给话音业务。造成GPRS连接拒绝和数据丢包率，出现掉线。 （因为语音和GPRS占用相同的信道（时隙），所以在语音通话时，GPRS必然断开，当结束后要重新连接GPRS。）   常用的几个GPRS模块： 1、GPRS DTU（GPRS数传单元，常称GPRS透传模块） 2、GPRS/GSM Modem（纯的GPRS/GSM调制解调器， 常称GPRS猫） 3、带TCP/IP协议栈的GPRS Modem（将Modem和TCP/IP协议栈封装在一起）   GPRS DTU（GPRS数据终端单元）内部封装完整的TCP/IP等协议栈，为无线传输提供透明的TCP/IP通道。 GPRS Modem是接入GPRS分组网络的一个物理通道，需要借助于外部的控制来完成DTU的功能。即DTU是使用Modem+MCU的组合。   DTU的四个核心功能： 1、内部集成TCP/IP协议栈； 2、提供串口数据双向的转换功能； 3、支持自动心跳保持永久在线； 4、支持参数配置，永久保存。   Modem的功能： 带TCP/IP协议栈的Modem在操作上还和普通的Gprs modem很类似，即：对所有的模块的操作时能用AT命令，尤其是发送和结束数据都要通过专用的AT命令。（这里就要自己实现串口的读写程序） /*----------------------------------------------------------------------------------------------------------*/ 2012-12-13 http://bbs.csdn.net/topics/210057079 GPRS 建立连接的过程中的一些注意事项。 http://bbs.csdn.net/topics/210029689 用AT指令操作GPRS模块时的一些概念   现在的理解， 关于AT指令建立了和网络的连接，相当于路由器， 但是和PC端的交互之间的协议 是PPP， 所以这个PPP需要PC端来执行， 同理将控制GPRS模块的MCU看做PC，这里就需要PC实现PPP来操作才可以。   是依靠模块自己建立GPRS网络连接， 还是自己使用PPP协议实现网络连接，   又似乎里边使用AT指令建立的网络连接是模块自己调用PPP完成的。   链路层： 硬件链路层 数据链路层   使用AT指令，这里的网络建立是有模块来维持的， 对于MCU只是收发数据而已。 GTM900C连接流程： http://bbs.gongkong.com/Details/200906/2009061320384200001-1.shtml 查询SIM：AT%TSIM  AT+COPS？ 查询信号质量：AT+CSQ? 对数据进行转换：AT%IOMODE=1,1,0 注册网关：AT+CGDCONT=1，“IP”，“CMNET” 查询GPRS网络：AT+CGREG? GPRS初始化：AT%ETCPIP=“user”，“gprs” 注册用户名，密码           AT%ETCPIP? 设置连接类型，地址，端口：AT%IPOPEN=“TCP”,"222.12.44.49",7002 发送数据：AT%IPSEND=“XXX” 读取数据：AT%IPDR

  因为使用GPRS进行数据的一些传输，在使用时总发现有些不是十分稳定。 以至于在修改时，都改到串口的读取上了（见《串口的初始化配置》）， 但是GPRS这里的问题还是没有得到真正解决。   以下关于GPRS的一些问题基于使用的是SIM900A模块的基础上。 主要遇到的问题： 首先是GPRS的连接时有时候会掉线，而且这个分时段，有时候很好，有时候就连不上。 其次是GPRS在发送数据的过程中，读发送的返回结果数据，但是这个时候可能将PC端发下的数据，一起读出来。 造成在真正读GPRS时，串口中没有数据，而造成数据丢失。   这里第一个问题，虽然想过解决的方法，但是都不是很理想，还是有一段时间会掉线造成连不上。没有找到更好的办法，能做的就是调整注册逻辑，保证掉线后尽快建立连接。 所以主要讨论关于第二个问题，因为它对于系统的影响最大。 如果在发送数据时，将之后需要读取的数据读到了返回结果的缓冲区中，这肯定要造成丢数据的现象。 所以这里另外设置一个缓冲区用来存放不是返回结果的数据， 在发送时，对读到的结果数据进行判断，如果此数据帧中只有返回结果数据，则不作其他处理。 如果在此次返回结果数据中还有其他数据，则将其他数据保存到设置的缓冲区中，并且记录其长度及设置相应的标识位， 在读数据时，判断相应标识位，如果设置了标识位，则根据记录的长度，将缓冲区中的数据取出，并就将缓冲区、标识位、长度记录清零，以备下次使用。 这样处理之后，发现效果好了很多，没有数据再因读发送结果而造成的丢失问题。 注：在写程序时，一开始还因为接收字节的设置小于实际的串口数据字节长度问题造成错误，这里要注意， 一定要保证接收字节的设置，一定要大于串口的数据长度，避免发生这种Bug。

晃眼间，又到了岁末评点的时节。在2007年初的技术展望专题中，我们讨论了手机、数字电视/移动电视、PMP、IP视频电话、视频监控系统，以及 RFID/NFC在2007年的发展前景和设计趋势，今天我们就来概括地回顾一下它们一年来的发展轨迹和最新进展，希望能对大家调整明年的发展策略有所帮 助。 今年初我们将下一代手机的设计趋势概括为三条：一是向EDGE和3G的多模方向发展，如GSM/GPRS/EDGE、GSM/GPRS/EDGE /WCDMA或GSM/GPRS/EDGE/TD-SCDMA，二是融合更多的无线功能，如移动电视、Wi-Fi、A-GPS和RFID读卡器/NFC 卡，三是单芯片设计。今天看来，总的预测是对的，但有些超前了，有些又落后了。例如，恩智浦和索尼已建立合资公司推广NFC在手机中的应用，但移动电视、 Wi-Fi和RFID读卡器尚看不到大批量地集成到手机中的迹象，而多模融合则已经跨越3G进入到3.5G范畴，今年11月中旬恩智浦、三星和T3G联合 宣布推出首款TD-SCDMA HSDPA/GSM多模手机就是明证，10月中旬博通推出的BCM21551多媒体处理器更是将下一代多模手机延伸到HSUPA领域，它将高速HSUPA 3G基带、多频带射频收发器、蓝牙2.1、调频收音机接收器和发射器集于一身，可同时支持HSUPA、HSDPA、WCDMA和EDGE蜂窝通信协议。 与3G手机市场终端产品先于标准出现的状况相反，中国数字电视标准DMB-T/H虽然已正式发布，但至今市场上还很难见到支持该标准的数字彩电，也 未见电视台大动作推出支持该标准的节目频道。这一现象发生的根本原因很可能是我们在年初指出的那样，该标准实现起来困难度比较大。虽说业界普遍相信明年奥 运会开幕之前，电视台会正式开播支持该标准的节目，奥运会的实况转播也会采用该地面传输标准，但预计中国数字电视制造商不会一步到位推出支持该标准的集成 式数字电视，而是更多地采用机顶盒的方式来支持该标准。 移动数字电视标准仍如我们年初所言的那样处于群雄争霸状态，不过业界普遍相信广科院推的CMMB标准最终将会胜出。由于业内普遍期望消费者能用随身笔记本电脑和手机等便携式设备收看北京奥运实况转播，因此很有希望明年上半年中国政府会拍板定案。 PMP市场诚如我们年初所预言的那样在缓慢增长，但估计它的黄金发展期将很难再出现，因为目前智能手机市场的高速增长正在模糊PMP在市场上的存在 意义。这一市场现状正迫使PMP向UMPC(超移动PC)和UIPC(超连接PC)方向发展，因为不管是UMPC还是UIPC都可在某一方面补足智能手机 的致命弱点：小显示屏、计算能力差、以及连接互联网和其它音视频设备的能力差。 IP视频电话的前景正变得越来越不明朗，这一方面是因为国内仍存在运营商的限制和政策上的不明朗因素，另一方面随着越来越多的消费者开始习惯在日益普及的PC/笔记本电脑上进行即时可视通信，IP视频电话的消费群体正变得越来越小。 视频监控系统也正如我们所预测的那样向网络化和智能化的方向发展，主要采用MPEG-4视频压缩标准的CCTV式视频监控系统虽然仍是当前业界的主 流，但基于IP和H.26?视频压缩标准的网络化智能视频监控系统已经出现在市场上，并受到广泛关注，这种系统能够一天24小时自动监控用户关心的财产和 人身安全，并智能分析风险等级，一旦超过设定门限，就能主动通过局域网和互联网将关键的视频图像信息发送到用户的手机或邮箱中，而不管该用户处于什么物理 位置。当然，用户也可主动通过互联网在全球任何角落随时了解监控区的一举一动。