游戏业务KQI特性研究演示文稿.ppt

1.1 游戏业务-指标定义 1.2 游戏业务-信令流程 控制面信令 特性：控制面信令游戏业务并无特别，分为RRC建立请求、业务请求和RRC重配过程，并且抓取当前较热游戏，王者荣耀、阴阳师等，都是建立在QCI=9上。 业务面信令 特性：在游戏过程中，TCP会建立多个服务器，且业务面使用了2种协议模式进行传输：TCP\UDP，并且有多个服务器同时进行。 1.3 游戏业务-用户感知时延 多人联网游戏特性 用户在游戏过程中，右上角会显示网络延时，当延时在150ms以下时，能够流畅的进行游戏体验，当延时变差时，用户会感觉到卡顿，施放技能、购买商品都不流畅，此时延为影响用户的第一感知要素。 用户感知时延 当前流行的APP互动游戏中，同步问题的本质是一致性的问题，在同一局多人游戏的过程中，玩家A看到玩家B的状态，应该跟玩家B自身看到自己的状态相一致。延迟是造成不一致的本质原因，假设理想情况下双方的网络时延都较小，那两者应该是同步的，但如果某一方玩家时延较大，则会对游戏的影响较大。 1.4 游戏业务-业务面信令特点 ①TCP/UDP协议共存 目前大多数交互游戏使用的为TCP协议，但是对于高效率的场景如PVP战斗过程中，TCP的拥塞控制和超时重传并不适合，也会采用UDP协议传输，在抓取【王者荣耀】游戏LOG中，存在TCP与UDP协议的共存 ②多个TCP连接并行 每局游戏中会建议多个TCP连接，且存在多个服务器。 ③56比特PSH包周期性持续发送 探测包的响应为3条消息，且以3秒为周期持续发送 1.5 游戏业务-信令节点与感知时延关联 游戏右上角时延为PSH探测包时延 TCP三次握手时延较PSH包时延相当，但当网络质量变化，而又未重新建立TCP时，三次握手时延无法反应游戏时延 传输间隔 PSH时延 PSH时延与右上角时延对应关系论证： 1、PSH包长都为56比特，而且在一个游戏服务器上以3s为周期持续发送探测； 2、PSH应答需要3条TCP协议连接，第一步为UE向服务器发送56bit包，服务器收到后确认上行同步，第二步为服务器向UE发送56bit包，第三步为UE向服务器确认已收到56bit包，用以确认下行同步； 3、根据统计，游戏右上角时延跳动和PSH时延基本保持一致。 TCP三次握手时延为7ms左右 人为使无线环境变差，未重新建立三次握手，PSH时延450ms左右 抓取一局游戏LOG，在游戏前半局过程中，网络情况很好，TCP三次握手时延约10ms左右，能较为客观的反映用户的时延感知情况，人为变差无线环境后，发现游戏右上角时延恶化为450ms左右，但从信令层面上来看，恶化过程中未出现TCP三次握手，游戏时延与PSH包时延相当。 1.6 游戏业务-方法论 游戏KQI信令节点计算公式 方法1 监测（APP DPI）：交互时延=目标服务器收到的第一个TCPack时间点-终端向服务器发起TCP建立连接请求的时间点。 信令节点公式： 交互时延=【UE向SP发送三次握手确认ACK的时间点】-【UE向SP发送三次握手请求SYN的时间点】 说明：该信令节点公式和字面意思吻合，统计为游戏过程中TCP建立过程中三次握手的交互时延。 方法2 信令节点公式： 交互时延=【UE向SP发送PSH探测包确认ACK的时间点】-【UE向SP发送PSH探测包的时间点】 说明：该信令节点公式与游戏内时延显示吻合，统计为游戏过程中的实时数据交互与同步时延。 KPI关联方法论 从对游戏业务特性的研究可以看出，实时交互性能是衡量游戏感知的重点，对相关KPI系能中，游戏业务对以下KPI性能较为敏感： 无线负荷性：资源利用率 无线保持性：切换成功率 无线保持性：掉线率 KPI定位 * * * * * * * * * * * *