数据业务组总结报告.docx

数据业务组总结报告数据业务组阶段报告A1. 概述42. GB口业务性能统计：93. GB口业务性能分析：错误!未定义书签。3.1失败原因分析133.1.1用户侧发起PDP去激活分析、143.L2小区更新过程分析:193.1.3FLUSH分析：203.1.4Response非成功状态码整体统计:273.1.5Response非成功状态码失败原因分析:283.1.6RadiO_cause分析.343.1.7SUSPend过程中伴随LLC.discarded的超时失败:353.1.8“SUSPEND”与“RESUME”的失败原因分析：363.2SP站点排名：423.3手机报内容大小分析：503.4终端端口设置及操作流程434.GB口下载速率分析：444.1各小区手机报下载速率统计：454.2手机报下载速率整体分析：466.GB口介入性时延分析：516.1AttaCh时延分布统计：511.2 PDP激活时延分析：521.3 TCP连接时延分析：537. MMS测试分析：568. EGPRS分析：609. GN口统计分析629.1GN口业务性能评估：629.2GN与GB关联分析649.3小结：6810.1MMl接口TCP连接分析6910.1.1TCP连接建立过程描述6910.L2TCP连接建立时延分析6910.1.3Syn至ack消息时延分析：7010.L4TCP连接建立成功率统计7010.1.5特殊的TCP连接统计：7110.2MMl口手机报接收分析7210. 2.1MMl口手机报接收过程描述7211. 2.2Get至Mretrieve.conf时延与成功率75H.PUSH接口信令分析7912. 1PUSH口统计分析7911.2PUSH口与MMl口关联分析7912.总结：82引言：项目管理区域范围：本次长沙移动GPRS手机报端到端性能优化服务涉及长沙市区的4个BSC与3个CQT点与有关的SGSN,GGSN51个WAP-Gateway与1套MMSC服务器C4个BSC如下:BSC404:BSC719:BSC728:BSC785:1 .概述湖南长沙移动手机报数据采集结构示意图如下所示:本次手机报业务数据采集要紧包含4个采集点，数据业务小组分别采集长沙移动现网的GB、Gn.MMl及PUSH等接口的数据用以专题分析。2 .成果综述本次项目通过GB,GN,MMl,PUSH多接口关联分析发现的要紧问题有如下4类：1) 用户自身问题：比如彩信中心地址设置错误，与流程没有结束用户主动释放等。能够告知用户正确设置来解决。2) 终端问题：终端协议有问题，多为山寨机。建议厂家修补bug。3) 无线环境问题：小区无线环境差。对小区进行无线环境优化。4) 网络问题：超时、网络无响应。由于GGSN/SGSN忙时丢弃掉的消息。长沙移动手机报优化成果如下：GB口分析要紧结果与发现：1) 网络侧超时无响应，要紧是用户频繁小区更新过程中网络超时无响应。2) 用户行为：用户主动去激活与彩信中心地址错误。3) 位置更新或者者语音业务抢占数据业务过程中超时无响应。4) 终端原因：终端协议问题，上报不符合规范的消息参数5) 网络连接中断6) FlUSh成功率过低。7) 小区更新(FLUSH)过程与位置更新(SUSPEND)过程严重影响手机报下载速率。8) 部分小区重传率过高。9) 手机渗透率相对较高 手机报集中下发高峰期的下载速率明显低于其他时段的手机报下载速率，网络的负荷过重时，对手机报的下载速率有着较大影响。 GN口手机报成功率与下载速率过低，GGSN繁忙无响应超时造成的手机报下载失败占比较高。 Push消息到GET消息之间平均时延为23.817S对手机报下过程中时间损耗奉献较大。 SGSN响应BSC发送的GET请求时间损耗较长为5S左右。通过无线配合测试发现，定点测试过程(非移动状态)中手机报下载成功率较高，同时下载速率比较稳固。彩信中心多次给部分手机下发PUSH消息用户没有手机报提取行为发生。要紧性能指标:接口成功率下载速率GB89.81%17.35(kps)GN80.16%ll58(kbps)MMl99.81%5394(kbps)PUSH97.56%1732(kbps)备注：其中GB,GN接口下载速率为getrequest到response消息时间差作为下载速率时间计算值。MM1接口下载速率为getrequest到m-retrieve-conf消息之间时间差作为下载速率时间计算值。PUSh接口下载速率以PUSh消息下发到MMI口收到getrequest消息过程时间作为计算下载速率时间差。手机报大小均以各接口统计手机报总大小比总次数得到平均值计算得到。接口TCP连接平均时延(MS)GB810GN998MMl8接口PDP激活时延(MS)GB174GN145由上表能够看出GN口TCP连接时间损耗最长是998ms,其次是GB口TCP连接时间损耗为810MS.MM1口TCP连接时间损耗为8ms对整个手机报下载过程来说能够忽略不计。Gb口与GN口PDP激活时延相差不大。基于上述分析结果建议如下:针对用户与终端建议如下：针对用户彩信中心地址设置错误，建议客服联系不一致厂家总结彩信中心地址设置汇总，对客户进行正确的彩信中心地址设置指导。工针对无线建议如下：1 .针对语音抢占数据业务导致超时无响应，建议修改无线参数降低小区CS/PS业务量。2 .针对网络断连的小区建议检查这些小区无线环境。3 .对网络负荷过重建议扩容。4 对数据流量大且移动性能不太好的小区，即导致TBF中断的小区重选间隔较短的小区，通过调整一些空闲模式参数，尽量减少小区重选，以提高其移动性能。5 针对重传率较高的小区LA参数调整建议：建议LA设置为ON,在C/I好的情况下尽可能使用高编码方式，在C/I低的情况下使用低编码方式，降低重传。6 PILTIMER调整建议：PacketIdleListTimer,当一个On-DemandPDeH处于空闲状态(Idle)时，将被系统放置在PS域的空闲列表，同时PILTIMER启动，当PILTIMER超时，On-demandPDCH将返回CS域。建议设置5秒，可提早释放GSL设备，降低GSL负荷。GSL是PCU与BSS之间的信令链路，所使用的协议为LAPD协议，故GSL链路又叫GDSLAPDo在BSC侧GSL定义于GPRC)C下，每个PCU可支持6个主用的GSL64kbps时隙与6个冗余备份时隙，每个64kbps时隙是一个LAPD信道，两条GSL工作于负荷分担模式。网络运行保护过程中定期分析现网GSL负荷，对负荷已经达到预警门限的GSL及时采取容量调整措施可有效保障GSL始终工作于最佳状态。7 建议EGPRS网络开通网络辅助小区重选与GBoverIP从而减少小区重选对手机报下载速率的影响与帧中继模式下Gb带宽不足问题。8 SUSPEND、RESUME失败要紧是在跨LAC,RAC,SGSN发生重选时造成的。想要解决这一问题需要添加GS接口。1针对核心网建议如下：1 建议修改GGSNqos_policymap里的参数TraffiCHandlingPriority能够大大提高PS业务的速率。2 建议调整SGSN寻呼响应计时器T3313值的设置，以减少寻呼响应时间。3 建议调整SM等待GGSN响应定时器的设置，以减少等待GGSN响应createPDPcontextresponse时间。4 建议SGSN开启对GGSN进行负荷分担功能，减少GGSN繁忙时负荷过重现象。5 为了防止个别用户激活PDP上下文后，长时间不适用PS业务而占用系统资源，GGSN应当配置最大空闲时间，在这个时间内假如用户没有流量，则能够主动去激活此PDP上下文。建议设置为15分钟。同时设置PDP上下文最大存活时间为15分钟。6 建议调整GGSN未收到SGSN响应报文时的重发时间间隔值，从而减少重传率。7 建议PUSH消息按时间分散下发，避免下发集中度过高。8 由于晚忙时下载速率与接入性各项指标均比早忙时要差，建议手机报晚忙时播报时间提早一个小时播报，同时用户躲开晚忙时下班路途中下载手机报，从而减少多次进行小区重选对手机报下载速率的影响。±针对无线建议的提出，通过无线优化人员配合无线参数调整优化前后指标对比：优化前优化后日期长沙手机报下载速率日期长沙手机报下载速率指标同比提升6月7日11.847JJ7日12.283.73%6月8日10.287月8日12.1518.19%6月9日11.137月9日12.3310.76%6月10日11.147月10日12.169.20%6月U日11.047月11日12.2711.23%由上表能够看出优化后手机报下载速率得到明显提高。3.GB口业务性能分析：数据采集时间点：6月25日从17：OO至下午20：00与6月26日从7:30到9:30o根据上述时间段内GB接口数据针对现网手机报业务的提取性能进行分析晚忙时25日(17:00-19:00)4个BSC总体手机报业务性能统计概况:晚忙时手机报接收概况类别次数比例手机报提取总次数6450100.00%提取成功次数579389.81%deactivate_pdp2043.16%flush_timeout1842.85%timeout841.30%Response非2xx761.18%Radio_cause(radiocontactlostwithMS)340.53%suspend_timeout330.51%Reset90.14%llc_discarded_timeout330.51%从统计结果能够看出长沙移动现网中4个BSC晚忙时手机报下发总次数为6450次，成功提取次数为5793次，成功率为89.81%,要紧的失败原因是timeout（超时无响应），其次是deactivate_pdp（用户去激活）与response返回的非成功状态码，最后是radio_cause（无线原因）引起的失败。另外值得关注的是timeout（超时无响应）失败中伴随flush（小区更新）的有184次占总提取次数的2.85%,伴随有SUSPend（语音业务抢占数据业务）的次数为33次占总提取次数的0.51%,是否由于小区更新过程中与suspend过程中出现特殊导致手机报的提取超时失败下面将进行深入分析。除此之外还有33次超时无响应是伴随有LLC-DISCARDED,尽管这种消息不一定造成手机报提取失败，但是这种消息的发生通常是由于小区无线环境差造成的。早忙时（7:30-9:30）4个BSC总体手机报业务性能统计概况:早忙时手机报接收概况类别次数比例手机报提取总次数4739100.00%提取成功次数439292.68%dcactivate_pdp1042.19%flush_timeout831.75%timeout591.24%Response非2xx450.95%Radio_cause(radiocontactlostwithMS)150.32%suspend_timeout170.36%Reset60.13%Ilcdiscardedtimeout180.38%比较早忙与晚忙统计概况，发现早忙的成功率92.68%要高于晚忙成功率89.81%o各类失败原因的所占比例排名相同，依然都是用户主动去激活与小区更新过程中的网络超时无响应。4个BSC晚忙时(17:00-79:00)手机报提取成功率统计如下:BSC成功率BSC4041639149991.46%BSC7191251108586.73%BSC7282061186390.39%BSC7851617145690.04%总体6568590389.88%由上表能够看出BSC404手机报提取成功率最高2个小时内下发1639条成功提取1499条，手机报提取成功率为91.46%,BSC719手机报提取成功率最低2个小时忙时内总的下发1251条成功提取1085条，手机报提取成功率为86.73%,BSC728在2个小时忙时内总的下发次数为2061下发次数最多，成功提取1863条，提取成功率为90.39%,BSC785在2个小时内总的下发1617条手机报，成功提取1456条，手机报提取成功率为90.04%早忙时段(7:309:30)4个BSC手机报提取成功率统计如下:BSC总提取次数成功提取次数成功率BSC40499693393.67%BSC71976771292.83%BSC7281547141791.60%BSC7851429133093.07%总体4739439292.68%同晚忙时段统计结果对比BSC404手机报提取成功率依然最高2个小时内下发996条成功提取933条，手机报提取成功率为93.67%,BSC728在2个小时忙时内总的下发次数为1547下发次数依然最多，成功提取1417条，提取成功率为91.60%,总体提取成功率为92.68%高于晚忙时89.88%o4个BSC晚忙时(17:00-19:00)各小区手机报提取成功率统计如下:各小区按照提取次数前20名列表如下:BSClac_ci比例M40429675_4751116415292.68%M72858358152313012293.85%M72858358_126111510490.43%M72858358_473011099587.16%M4042967546621069892.45%M71929675246031017473.27%M78529643_8043968992.71%M71929675_1673957174.74%M72858358_1263948590.43%M7192967524601937782.80%M40429675_4661897685.39%M40429675_26002857891.76%M40429675_23561817488.10%M71929675.4281847690.48%M72858358_7303837286.75%M40429675_47512826781.71%M72858358_1522797392.41%M7285835824231787393.59%M71929675_1672776280.52%M71929675_55800767197.37%上表中黄色部分标出的是成功率相对较低的小区。全面列表见附件:各小区晚忙提取成功率.xls4个BSC早忙时(7:30-9:30)各小区手机报提取成功率统计如下:各小区按照提取次数前20名:BSCLA(LCl总提取次 数成功提取 次数成功率M72858358 152313812792. 03%M78529643 804311310895. 58%M72858358_47301807695. 00%M40429675_47511777698.70%M71929675_46242817390.12%M40429675_47512807290.00%M4042967523561716794.37%M72858358_24293736690.41%M71929675_56243686494.12%M40429675_47523605998.33%M78529643_1891605693.33%M72858358_24231575698.25%M78529643_47051595593.22%M72858358_24292565496.43%M72858358J9631605185.00%M78529643_32614949100.00%M72858358_11891514996.08%M71929675_1673524994.23%M728583581261604880.00%M72858358.47303524790.38%上表中黄色部分标出的是成功率相对较低的小区。各小区:丽艮下载全面请见附件：成功率早忙Xk3.1失败原因分析首先看下正常接收手机报的流程，下图为WAP手机报提取过程:S218；a(B色>00.222.19410.1；15:07:50400RADiusjAccourtingfiequesI浙tWAPCI>0,5,4810.0.0.172/atewayMNBJ,211.136.23.7211.1315053,689HTTPJGetSCB7.85.180,8613547010092,15:07:57432RADlUSccourtingfiesponse15:08:09482RADiusjAccounting-Request15:07:52277WSPConned,30860,15:07:52,891WSPlConnedReply,3086015:07:53508WTPJACknOWtedge,3086015:07:53,569WSPGel、,30861人即:211,137.85.180/240706388E15:07:53705MMSmret11vconf/1507:531694lMMS)m-retrieve-cori1507r55,829(MMS)HnacknowIedgeind、J086100X)KzSuccess(32)15:07:54,928pTPJAcknowIedge,3086115:07:55749MMSmacknow<edgd、z30862http:cnmsc.mOntefheI811t80/,15:07:55'850WSPReply,15:07:55831HTTPResps,30862200QK,Success132)180804'547WTPJAcknov4edge和862,8613547010092/15:08:09,513RADIUSJAccouhting-Re$pon5e3.1.1用户侧发起PDP去激活分析:1.POST消息之前用户侧发起PDP去激活典型流程部分截图如下图:Z6146917:37:S61227BSC->SGSM2161S842161920216193221620682171619217172621738622174S1421746702175412Z17S420217642921754352175440217544117:37:56,26817:37：S6,3761?:37:56,38017:37:56141917:37:59,72717:37:59,76917:38:00,48717:39:00,7291*7:38:00'78517z3801,05817:38:01106117:38:OL06217:38:01,06517:38:OX'06717:38:01,069BSC<-SGSHBSC<-SGSNBSC->SCSHBSCV-SGSNBSC->SGSHBSC<-SGSMbsc->scshBSC>SGSNBSC<-SGSNBSC<-SGSNBSC<-SGSWBSC<-SGSWBSC<-SGSNBSC<-SGSWBSC<-SGSH(GMMSMcvacPDPcont*xcrequest,CI:47641lessGP)Wi-Capability-Updati-acktGHKSKJAcexvtPDPcont×Zaccept(BSSGPlFL0W-C0HTR0L-KSIbssgpiflow-Comtrol-Hs-ACkTCPJSyn,CI:47641,N-PDUmuab6：。(TCP)Ack,Syn,N-PDUnumber:0TCP)ck.Cl:47641,N-PDUnu*br:1(HTTPGt,Cl:47641,N-PDUnuab«r:2,URI»Ain：211.136.112.8'(TCPJAck,N-PDUnu>b«r:l(HMS)a-rcriev-conf,N-PDUmutb":2,Stcu%Cod:200OK,：(SNDCPSW-UNITDT,N-PDUnuabr:Z(SNDCPjSN-UNITDATA,M-PDUnt>brr2(HTTP】_HTTPaeSMij,N-PDUnumber:3(SndcpTsn-UNITDATA:N-PDUnuab«r:3(sndcpjsn-unitdta,n-pdunumber：3220217922021902202196220220922022182202221220339722035642Z0S10822052Z0220707422071732208809220903422102972210S4722109412210998221227S22131562213216Z213S80221370422137822216201223S150223S26S2235S7917:36:10,191BSC<-SGSN(HTTP_HTTP_Seg*«ne_,M-Pt>Unuab«r:3S17:38:10*194BSC<-SGSN(SNI>CP7sN-UNITDT7M-PDUnuab«r:3S7：3:IU,135B5U<-Sk>5NISND“JSN-UHl.1DAIA,N-PDUnuad>r：337:38:10,197BSCV-SGSNHTTP_HTTP_Seg»ent_,N-PDUnuabrr367:38:10,199BSC<-SGSN(SNDCPTsN-UNITDT:N-PDUnumber:3617：38：10'Z0117:38:10-64817:38:10,69217:38:11,24917z38rll,28917:38:11/94817:38:11-98817:38:12,52817:38:12,60817:38：13(06417:38：13*14617:38:13*28817:38:13,30817:38:13*76817:38:14,06517:38:14*09017:38：14*20817:38:14,24817:38:14,26817:38:15,10417:39:21,63017:38:21(67517z3821,776BSC<-SCSNBSC>SCSNBSC->SGSNBSC>SGSNBSC>SGSNBSC->SGSNBSC>SGSNBSC>SGSNBSC->SGSNBSC>SGSNBSC<-SGSMBSC->SGSHBSC>SGSNBSC->SGSHBSC>SGSNBSC<-SGSHBSC>SGSHBSC>SGSNBSC>SGSHBSC>SGSNBSC>SGSMBSC<-SGSHBSC«SGSN(SNDCPjsn-unitdata(TCPAckrCX:47641,N-PDUTCPck,S:47641,NPDU(TCPJAck,CI:47641,N7DU(TCPJAck,CI:47641,N-PDU(TCPJAckzCI:47641,N-PDU(TCPlAck,CI:47641,N-PDUTCPJAck,CI:47641,N-PI>U,N-PDUnutober:36ntmb*r:20nu>br:21nuabr:ZZnuabr:23number:24number:25nu>b*r:26ITCPIAck,CX:47641,N-PDUnuMb«r:27(BSSGPFLOW-COKTROL-HSIBSSGPFLOW-CONTROL-KS-ACK(TCP)Ack,CI:47641,H-PDUnuBber:28(TCPIAck,CI:47641,N-PDUnu*ber:29(TCP)Ack.CI”7641.N-PDUnu>b«r:30(BSSGP)FLOW-CONTROL-KSBSSGPFlow-Control-MS-ACK(TCPck(TCPJAck(TCPAck(TCP)Ack,CI：47641,N-PDU,CI:47641,N-PDU,CI：47641,N-PDU,CX：47641,N-PDUITCPIAckrFln,Cl:47641,N-PDUnuub«r:3S(TCPck,N-PDUnumber:37(TCPIAck,Fin,N-PDUnuber382237484I7:38:22469BSC-ASCSH(TCP)ACk,CI:47641，N-PDUnu>ber:36224JL7961一一一”，9|»/；山"LUuSjU224204017:38:24'031BSCY-SGSNIGHHSH)DeaCtiVaSPDPConSXCaccpt第36个分包消息全面解码如下:13秒*7641,SHCause:IP:Destaddressvalue:179876877IP:SUmofIPAddressValue:347649209TCP:TCPSourcePort:80TCP:TCPDestPort:1070TCP:Sumo£SrcandDeSCPort:1150TCP:!SequenceNumber:727B53BB(1920684987)TCP:ZAcknowledgeNuiaber:7FEB3E39(2146123321)TCP:Dataof£se:8TCP:Urgent.pointer:0(0)lCP:Ackfieldflag:Set(I)TCP:Push:Notset(0)TCP:Reset:NotSet(0)T11DhH>tiNQMCtTCP:Finish:Horedatafromsender(0)TCP：UyPe，.J,，土TCP:ExpectedAcknowledgeNtunber:727BS8FF(192068633S)TCP:Window:64704TCP:TCPLength:444HTTP:Messagetype:_HTTP_Segment_(-1)由于流程太长上面流程截图中忽略掉中间部分下发分包消息，从上面流程能够看出该用户在17：37:56227的时候发起PDP请求随后通过tcp连接三握手后于17:38:00729发起get请求开始下载手机报内容，随后手机报内容被分割下发，一直下发到17:38:10'197时的第36个分包，我们看到第36个分包消息的全面解码，发现TCP中Finish:moredatafromSender,说明这不是最后一个分包消息，还是否具有下发的分包消息，用户13秒钟后仍然没有收到最后一个分包消息，开始发起deactivatePDPcontextrequest,流程失败。至于为何网络侧没有下发最后一个分包后续将关联其他接口做深入分析。2、Post消息之后的PDP去激活失败流程分析典型流程部分截图如下：B994787Z99S0382995660299S769Z99599ZZ99864ZZ9988Z03001544300176930020813002086300209430020993002113305099530S10043051016¾0510233051024305102830510353051038305403430546173055782305595830S602630560Z930562213056224305622730S806S.310323s(17:42:3S'76417:42:3S'83Z17:4Z:36,00317:42:36,0Z617:42:36,08Z17:42:36,80517:4Z:36'8S117:42:37'56517:42:37,62717:42:37,71717:42:37,71917:4Z:37,72117:42:37,72217:4Z:37,72417:4Z:50,97617:4Z:50,97817:42:50,98017:4Z:50,98Z17:4Z:50'98S17:4Z:50,98617:4Z:50,98817:4Z:S0,99017:42:S1,85717:4Z:52,031BSC>SGSNBSC<-SGSNBSC<-SGSNBSC>SGSNBSC<-SGSNBSC>SGSNBSC<-SGSNBSC>SCSMBSC>SCSNBSC<-SGSNBSC<-SGSNBSC<-SGSNBSC<-SGSNBSC<-SGSNBSC<-SGSNBSC<-SGSNBSC<-SGSNBSC<-SGSNBSC<-SGSNBSCv-SGSNBSC<-SGSNBSC<-SGSNBSC>SGSNBSC<-SGSNGHMSHActivatePDPcontextrequest；BSSGPFLUSH-LLGHHSHActivatePDPUOnteXtacceptBSSGPFLOW-CONTROL-HSBSSGPFLOW-CONTROL-MS-ACKTCPSyn,CI：14210,N-PDUnumber:0TCPAck,Syn,N-PDUnumber:0TCPJAck,CI：14210,N-PDUnumber:1HTTPJGet.,CI:14210,N-PDUnumber:2zUPHHSn-retrieve-conf,N-PDUnuxber:1,SNDCPSN-UNITDATA,N-PDUnumber:1SNDCPSN-UNITDATA,N-PDUnumber:1HTTP_HTTP_Segment._,N-PDUnuxiber:2【HTTP二HTTP二Segillent二,N-PDUnuxiber:3HTTPHTTp2,Segaent",N-PDUnmber:50SNDCP?SN-UNITDATA二N-PDUnuberzSOSNDCPSN-UNITDATA,N-PDUnuberzSO(HTTP_HTTP_Segiaent._,N-PDUnmber:51*SNDCP?SN-UNITDATA二N-PDUnuniber:SlSNDCPSN-UNITDATA,N-PDUnuberzSlHTTP_HTTP_Segaent_,N-PDUnvmberzS2SNDCP?SN-UNITDATA二N-PDUnuberzS2TCPJAck,CI:14210,N-PDUnun»ber:29TCPJAckzFin,N-PDUnuinber:53早4J<召GG-GGG»T奇GiM>-77:4Z:5Z'459BSC>SGSNIHTTPlPogtCL1421。.N-PDUnumber:3117:4Z:52,48117:42:52,48117:42:52'54217:42:5Z'S4Z17:42:S2'5431。4”CaICQr7BSC>SGSNBSC>SGSNBSC<-SGSNBSC<-SGSNBSC<-SGSNSNDCPSN-UNITDATAzCI:14210,N-PDUnumIHTTPJ_HTTP_Segment_zCI:14210zN-PDUnTCPAck,N-PDUnumber:54TCPAck,N-PDUnumber:55TCPAuk,Reset,N-PDUnumberITD13CbRirld2icILT-DZT17:43:07'165BSC-ASGSNGHMSHlDeautivatePDPConteXtrequest1O3S1117:43:07'Z49BSC<-SGSNfGISMlDeactivatePDPcontextaccet,14秒，第52个分包消息的消息参数如下:由上图能够看出手机报分割下发后，下发到第52个分包消息，通过该消息参数能够看到这个分包消息IP：totallength:823比以上所有分包消息都小，手机终端认为这个分包就是最后一个分包消息，随后向网络侧发起接收完成回应消息POST,手机接收彩信完成，PoSt消息参数如下：TCP:Ackfieldflag:Set。)TCP:Push:Set(I)TCP:Rese:Notset(0)TCP:Synchronize:Notset(0)TCP:Finish:Moredatafromsender(0)TCP:Messagetype:AckzPush(24)TCPrrExpectedAcknowledgeNuiober:3BE892DF(100S09769S)TCP:Window:32768TCP:TCPLength:444HTTP:MaW“qarypjPcwr44)HTTPRequest-URI:http:/m