故障定位方法及装置的制作方法

文档序号:7910070阅读:102来源:国知局
专利名称:故障定位方法及装置的制作方法
技术领域
本发明涉及通信领域,具体而言,涉及一种故障定位方法及装置。
背景技术
网络电视(Internet Protocol Television,简称为IPTV)的大规模运用,引发了电信运营商的变化,逐渐从单一网络提供商/服务提供商转变为综合业务提供商,从以往关注设备管理、网络管理到相应的服务质量管理,并且需要满足IPTV用户使用IPTV业务时期望得到如有线电视相同的服务质量等。因此,电信运营商在用户使用IPTV业务出现播放异常时,需要进行快速的故障定位与处理,缩短用户故障时间,提高用户的业务体验满意度。针对上述技术问题,在相关技术中提出了几种解决方案,下面对这几种解决方案进行说明。方案一申请号为“200910146780. X”发明名称为“一种IPTV业务故障处理方法、 装置及系统”的专利申请文件中公开了 电子节目单元EPG服务器接收用户终端确定鉴权认证服务器发生故障时,发送的应急连接请求消息,该消息中至少携带用户终端在上一次登录IPTV系统时使用的临时用户身份标识ID ;所述EPG服务器根据所述临时用户身份ID 确定所述用户终端为合法用户,以及确定该临时用户身份ID未超过相应的有效期限时,允许所述用户终端使用指定的IPTV业务。这样,当鉴权认证服务器发生故障时,EPG服务器允许用户终端以应急状态使用基本的IPTV业务,从而在不影响用户使用的前提下,保证了 IPTV系统的服务质量,也保证了系统的安全性。方案二申请号为“200810055838. 5”发明名称为“一种IPTV接入网的测量装置及测量方法”的发明申请中公开了 该IPTV接入网包括运营支撑系统、流媒体服务系统、视频源系统及用户终端,该流媒体服务系统又包括中心流媒体服务器和边缘流媒体服务器, 所述测量装置又包括NAT网络测量通道设置模块,用于在位于公网的边缘流媒体服务器与位于私网的该用户终端之间建立测量通道,创建测量报文并进行网络质量测量;网络时延计算模块,用于在网络质量测量中计算网络时延;报文丢报率的测量模块,用于通过在设定的系统周期内定时统计从发送端到接收端的测量报文数量,来计算出丢报率数据。本发明还公开了一种IPTV接入网的测量方法。本发明能够迅速定位及解决网络问题,从而提高 IPTV网络的业务服务质量。方案三申请号为“200610163987. 4”发明名称为“排除第2层聚合网络中多播连接流问题的诊断工具和方法”的发明申请中公开了 发现与发起所述IGMP加入操作的目标设备关联的MAC地址;通过一个或者多个中间节点向所述目标设备发送包含所发现的MAC 地址的请求消息;从所述一个或者多个中间节点和所述目标设备接收一个或者多个回复消息;以及分析所述一个或者多个接收到的回复消息以确定哪个中间节点和/或目标设备由于不成功的IGMP加入操作而没有更新位于其内的转发数据库。方案四申请号为“200820225918. 6”发明名称为“一体化可便携的IPTV仿真测试装置”实用新型申请中公开了 装置包括IPTV机顶盒和显示器,增设了电源控制模块和电池,其中IPTV机顶盒(Set Top Box,简称STB)的音频和视频输出端口对应接至显示器的音频和视频输入端口,IPTV机顶盒的输入端接外来信号,电源控制模块的输出端口分别和 IPTV机顶盒、显示器的电源输入口相连,电源控制模块的输入端口分别接至电池端口 C0N2 的电池和交流电源接口 CONl的交流电源。本测试装置将IPTV机顶盒、显示器和电池,用电源控制模块有机地整合成一个便携式的一体化测试装置,能够在用户家里或没有电源的室外接入位置,通过显示器的显示图像效果,直观的评测IPTV输入信号的质量状况,快速诊断出故障段落,是通信运营商的维护人员进行IPTV业务维护测试的有效工具。但是上述的方案在发现与定位组播类故障存在不足即在上述方案中都是在了解大概的故障点后,进行进一步具体的故障分析,而无法在IPTV系统整体中进行故障的定位。

发明内容
本发明的主要目的在于提供一种故障定位方法及装置,以至少解决上述问题。根据本发明的一方面,提供了一种故障定位方法,包括以下步骤从机顶盒和/或预先设置在IPTV系统中的业务监控点获取IPTV业务的监控数据;根据所述监控数据中的一个或多个参数的值依照对应关系定位所发生故障,其中,所述对应关系为预先设置的参数取值与故障的发生之间的关系。优选地,在根据所述监控数据中的一个或多个参数的值依照对应关系定位所发生故障之前,所述方法还包括根据用户上报的信息和/或根据所述监控数据确定的平均意见得分MOS值确定发生故障。优选地,根据所述监控数据中的一个或多个参数的值依照所述对应关系定位所发生故障包括根据所述监控数据确定所述IPTV系统中发生所述故障的位置,和/或,确定发生所述故障的故障类型。优选地,确定所述故障发生在以下位置的至少之一所述IPTV系统的头端、所述 IPTV系统的业务平台、所述业务平台到机顶盒之间的接入网、所述机顶盒。优选地,根据所述监控数据确定所述IPTV系统中发生所述故障的位置包括根据所述监控数据判断所述故障发生的范围的大小;根据所述范围的大小确定所述IPTV系统的架构中能够对所述范围的带来影响的位置发生故障。优选地,在根据所述监控数据判断所述故障发生的范围的大小之前,所述方法还包括根据来自所述机顶盒的监控数据确定所述机顶盒未发生故障,以及,根据来自监控头端的业务监控点的监控数据确定来自所述头端的数据正常。优选地,确定所述故障的故障类型包括以下至少之一仅涉及到频道的故障、视频编码故障、承载所述IPTV的网元或者线路出现的故障。优选地,所述监控数据包括以下至少之一所述IPTV业务的服务质量信息;来自用户的平均意见得分值。优选地,从所述机顶盒获取所述监控数据包括以下至少之一所述机顶盒周期性上报所述监控数据;通过所述机顶盒上的抓包工作所抓取的数据包获取所述监控数据。根据本发明的另一方面,提供了一种故障定位装置,包括获取模块,用于从机顶盒和/或预先设置在IPTV系统中的业务监控点获取IPTV业务的监控数据;定位模块,用于根据所述监控数据中的一个或多个参数的值依照对应关系定位所发生故障,其中,所述对应关系为预先设置的参数取值与故障的发生之间的关系。优选地,所述装置还包括定位模块,用于根据用户上报的信息和/或根据所述监控数据确定的平均意见得分MOS值确定发生故障。优选地,所述定位模块用于根据所述监控数据确定所述IPTV系统中发生所述故障的位置,和/或,确定发生所述故障的故障类型。优选地,所述定位模块包括判读模块,用于根据所述监控数据判断所述故障发生的范围的大小;确定模块,用于根据所述范围的大小确定所述IPTV系统的架构中能够对所述范围的带来影响的位置发生故障。通过本发明,采用从机顶盒和/或预先设置在IPTV系统中的业务监控点获取IPTV 业务的监控数据;根据所述监控数据中的一个或多个参数的值依照对应关系定位所发生故障,其中,所述对应关系为预先设置的参数取值与故障的发生之间的关系,解决了无法在 IPTV系统整体中进行故障定位的问题,进而可以在IPTV系统中进行整体的故障定位,为提高IPTV系统中故障处理效率提供了保证。


此处所说明的附图用来提供对本发明的进一步理解,构成本申请的一部分,本发明的示意性实施例及其说明用于解释本发明,并不构成对本发明的不当限定。在附图中图1是根据本发明实施例的故障定位方法的流程图;图2是根据本发明实施例的故障定位装置的结构框图;图3是根据本发明实施例的定位模块的结构框图;以及,图4是根据本发明优选实施例的故障定位方法的流程图。
具体实施例方式下文中将参考附图并结合实施例来详细说明本发明。需要说明的是,在不冲突的情况下,本申请中的实施例及实施例中的特征可以相互组合。在本实施例中提供了一种故障定位方法,该方法可以应用在服务器中,该服务器可以是一个或者一组服务器,当然,也可以作为一个模块添加到现有的服务器中,采用哪种方式可以按照实际的网络情况来进行选择。在下文中,为了描述方便,将提供了该故障定位方法的服务器或者模块统一称为IPTV服务质量监控系统,该系统中所提供的服务器可以是一个也可以是多个。在本实施例中提供了一种故障定位方法,图1是根据本发明实施例的故障定位方法的流程图,如图1所示,该流程包括如下步骤步骤S102,从机顶盒和/或预先设置在IPTV系统中的业务监控点获取IPTV业务的监控数据;步骤S104,根据该监控数据中的一个或多个参数的值依照对应关系确定定位所发生故障,其中,对应关系为预先设置的参数取值与故障的发生之间的关系。在上述步骤中,预先设置了出现不同的参数值或者不同的参数值组合时与可能发生的故障的对应关系,该对应的关系的获得可以是经验的积累或者是通过在测试阶段所获得的数据来进行的,无论通过哪种手段,只要得到了该对应关系就可以为故障发生原因的判断提供依据,并且,对于该对应关系也可以不断进行更新、完善。在有了对应关系之后,可以根据需要来设置业务监控点,在某些情况下,如果仅从机顶盒的监控数据就可以得到故障原因的情况下就可以不增设业务监控点,因此,可以根据实际网络的架构或者IPTV业务的需要来进行业务监控点的设置。通过上述步骤,相比与现有技术只能对特定的故障进行定位的方式,本实施例可以根据实际的需要设置监控数据的来源,从而可以在IPTV系统中进行整体的故障定位,为提高IPTV系统中故障处理效率提供了保证。对于监控数据的获取,可以是机顶盒或者业务控制点主动上报的,例如,可以设置上报的周期,如果需要较多的上报数据,可以将上报周期设置的比较短,如果需要较少的数据,可以将上报周期设置稍长。如果上报周期设置的足够短,那么就起到了相当于实时上报的效果。当然,如果希望IPTV监控系统能够主动控制机顶盒或者业务控制点来进行上报, 也可以在机顶盒或者业务控制点中设置抓包工具,通过该抓包工具,IPTV系统可以抓取到所需要的监控数据。在获得监控数据之后,IPTV监控系统可以周期性的对该监控数据进行分析,从而可以确定是否发生故障。当然,可以直接根据用户上报的信息来确定是否发生故障。对于监控数据的分析,可以引入平均意见得分MOS值的方式来判断用户的主观感受,平均意见得分是根据用户的主观感受来对服务质量进行评价的一种方式,例如,可以向用户提供选择界面,在该界面中,可以提供一些问题(如,观看是否流畅?是否存在黑屏想象?是否有马赛克等),根据用户的这些打分来确定MOS值;又例如,可以根据监控数据中的一些数值由IPTV监控系统来确定的MOS值,例如,实际的比特率、机顶盒所能使用的带宽等等。在得到MOS值之后,就可以根据该MOS值来确定是否有故障发生了。通过这种方式,可以根据用户的主观感受来判断故障的发生,站在了用户的角度,对于单个用户而言,提供了其用户体验。在本实施例中,对于“故障”可以是单个用户主观感受的变差就作为故障,也可以是其他的一些故障,为了更加精确的定位,在本实施例中,可以将故障发生定位为在IPTV 系统中发生故障的位置(例如,IPTV系统的头端、IPTV系统的业务平台、业务平台到机顶盒之间的接入网、机顶盒)和/或故障的类型(例如,仅涉及到频道的故障、视频编码故障、承载IPTV的网元或者线路出现的故障),这样的分类对于故障的查找比较方便。例如,一个故障如果是多个用户均发生的,那么可以定位该故障发生在IPTV系统中的架构的位置。在定位到位置之后,再定位故障类型。当然,对于有些故障是不需要定位故障位置的,有些故障是不需要定位故障类型的,例如,网络的中断,直接定位网络中断的位置即可。例如,收到机顶盒的错误报警,那么直接定位该报警对应的故障类型即可。也可以是对故障发生位置和 /或故障类型的定位。对于确定IPTV系统中发生故障的位置,在本实施例中提供了一种比较优的处理方式,该处理方式,可以根据监控数据判断故障发生的范围的大小,然后再根据范围的大小确定IPTV系统的架构中能够对范围的带来影响的位置发生故障。例如,如果是某个小区的机顶盒均发生故障,那么可以确定是掌管该小区机顶盒的设备发生了故障,如果是某个地区的机顶盒均发生故障,则可以确定是该掌管该地区的机顶盒的设备发生故障等。
对于监控数据而言,其包括以下至少之一 IPTV业务的服务质量信息;来自用户的平均意见得分值。这两种信息是均可以体现用户的直接感受,使用这两种信息进行判断可以直接提高用户实际接收到的IPTV业务的质量,提供用户的体验。在本实施例中还提供了一种故障定位装置,图2是根据本发明实施例的故障定位装置的结构框图,如图2所示,该故障定位装置包括获取模块22和定位模块M。下面对该装置进行说明。获取模块22,用于从机顶盒和/或预先设置在IPTV系统中的业务监控点获取 IPTV业务的监控数据;定位模块M,用于根据该监控数据中的一个或多个参数的值依照对应关系定位所发生故障,其中,该对应关系为预先设置的参数取值与故障的发生之间的关系。优选地,该定位模块M,用于根据用户上报的信息和/或根据该监控数据确定的平均意见得分MOS值确定发生故障。优选地,该定位模块对,用于根据该监控数据确定IPTV系统中发生故障的位置, 和/或,确定发生所述故障的故障类型。在本实施例中还提供了一种故障定位装置中定位模块的优选实施方式,图3是根据本发明实施例的定位模块的结构框图,如图3所示,该定位模块M包括,判断模块32和确定模块34,下面对该模块进行说明。判断模块32,用于根据监控数据判断故障发生的范围的大小;确定模块34,用于根据上述范围的大小确定该IPTV系统的架构中能够对范围的带来影响的位置发生故障。以下结合优选实施例进行说明,在本优选实施例中,考虑到IPTV中组播业务较多,因此,以组播类节目播放异常为例来进行说明,并且,在本优选实施例中,对于监控数据是以QoS数据为例进行说明的。在本优选实施例及其优选实施方式中,提供了一种电子化流程进行故障定位的方案。该方案通过整合IPTV业务系统中可实现的测试方法与QoS数据,对相关的指标数据进行分析,与用户报障流程进行有机地结合,实现了用户报障、故障定位、故障处理的自动化运维保障流程。本优选实施例及优选实施方式对难于分析的用户体验或用户感知(Quality of Experience,简称为QoE)故障可进行有效的分析与定位。需要说明的是,这些优点并不是每个优选实施方式都具有的,有些优点只有某个特定的优选实施方式才具有。图4是根据本发明优选实施例的故障定位方法的流程图,如图4所示,该流程包括如下步骤步骤S402,用户开机使用IPTV业务,机顶盒实时记录QoS数据,并定期上报至 IPTV服务质量监控系统(例如,该系统中的服务器管理设备)。其中,在该机顶盒记录之前, 会对机顶盒进行预先配置,例如,配置相应的Q0S采集与上报参数,包括以下至少之一 QoS 参数采样周期、QoS数据上报周期、QoS数据上报地址。另外,需要指出的是,机顶盒定期上报QoS数据是主动的,而非IPTV服务质量监控系统通过远程抓取网络报文来实现。需要说明的是,该机顶盒实时记录的QoS数据包括但不限于用户观看与用户观看频道与视频点播(Video On Demand,简称为V0D)相关的带宽、网络抖动、丢包率、延迟因子 (Delay Factor,简称为DF)、媒体丢包率(Media Loss Rate,简称为MLR)、EPG连接时长、认证时长、认证成功率,播放失败次数、播放失败错误码。IPTV服务质量监控系统根据实时接收到的用户机顶盒上报的QoS数据后,进行实时的数据处理与统计,并可通过系统界面展示给运维人员。例如=IPTV服务质量监控根据用户机顶盒上报的QoS数据,实时计算用户、频道、VOD节目的平均意见值(Mean Opinion kore,简称为M0S)。其中,该MOS值的取值范围为O到5。针对不同的业务,可以对MOS的区段值所代表的用户感知进行描述。例如,如果MOS彡3,则用户感知描述为“由(故障类型)导致传输质量下降,用户感知有马赛克及卡顿”;如果3 < MOS < 4,则用户感知描述为“由(故障类型)导致传输质量偶尔下降, 收看时有轻微马赛克或卡顿”;如果4彡MOS < 5,则用户感知描述为“由(故障类型)导致传输质量未受影响, 收看时有偶尔卡顿且不易察觉”。步骤S404,用户的组播类节目播放中出现异常时,IPTV服务质量监控系统分析机顶盒的QoS/QoE参数是否异常。组播类节目为组播方式承载的媒体业务,主要是直播频道类节目。用户的组播类节目播放中出现的异常属于用户播放组播频道的异常,而非用户账号错误、EPG访问失败等接入性的异常。这些异常主要体现为播放界面卡、黑屏、马赛克、图像模糊、播放中断等。发现组播类节目故障的方式,可以是通过最终用户上报(即用户报障),也可以是运维人员通过监控系统发现用户的相应体验指标异常。用户的组播类节目播放中出现异常时,可以确定出故障节目基本信息,此故障频道基本信息包括故障用户账号、相关的STB 设备信息、用户观看的故障频道名称、故障发生时间、故障持续时间。IPTV服务质量监控系统分析该机顶盒的QoS/QoE参数,从而确定异常可以有以下几种方式通过机顶盒实时上报的QoS数据进行判断,也可以通过机顶盒远程抓包工具进行远程抓包,从而分析QoS数据是否异常。正常情况下,用户机顶盒的所有使用情况以及QoS数据都会存储在IPTV服务质量保障系统中。运维人员通过查询用户故障时间段的MOS值以及详细QoS数据,判断用户QoS 故障参数。例如,用户MOS值应小于4,相关QoS异常可能表现为DF与MLR值较大,例如, DF超过了 50ms,MLR超过了 5。如果此时段用户MOS值大于4,则说明可能是用户机顶盒物理故障或者视频本身存在编码异常。步骤S406,分析监控点组播指标数据,从而判断组播入口是否异常。其中,该组播指标数据包括丢包率,网络抖动、DF、MLR等QoS参数以及视频编码TR101290参数。组播码流监控可采用在接近头端系统的位置部署组播码流监控设备,也可以通过监控系统从IPTV业务系统采集数据分析。组播码流监控服务器(或称为组播码流监控点) 可以部署在头端与IPTV系统的入口侧,也可以部署在IPTV平台内各节点旁。如果媒体指标数据异常,则可以判定除上一个正常监控点到异常监控点之间网络存在异常。如果此监控点就是头端监控点,则说明是头端码有异常。如果监控点发现组播频道TR101290视频编码有异常,则说明组播源过来的视频编码格式存在问题。步骤S408,在机顶盒用户QoS数据正常并且上述入口组播指标正常的情况下,可以从IPTV服务质量监控系统中查看同一地区、全局用户观看同一频道的情况,是否存在普遍性的异常。如果故障用户具备相应的地区普遍性,并且该地区用户观看其他频道节目正常,则判定出IPTV业务平台转播该频道存在问题;如果故障用户具备相应的地区普遍性, 并且该地区用户观看其他频道也存在普遍性异常,则判定出从IPTV业务平台到用户的接入网存在故障。步骤S410,在从IPTV业务平台到用户的接入网存在故障的情况下,判定用户的接入设备是否存在故障。如果该地区用户观看其他频道类故障具备普遍性,单播类节目没有明显普遍性故障,并且故障用户都在同一个组播复制点下,则判断出该组播复制点对组播复制存在异常, 如果普遍性不是组播复制点或者在不明确组播复制点的情况下,则判断出该地区的关键上联数据设备对组播支持存在故障。通过本发明实施例及优选的实施方式从整体上对故障进行定位,从IPTV服务质量管理系统的相关指标数据获取,以及对该指标数据进行分析推导,在不同的层次上进行定位故障分析,最终确定故障原因,缩短了 IPTV运营商的故障处理时间,极大地提高了 IPTV运营商的运维保障能力,提高了最终用户的满意度。另外,本优选实施例充分利用现有 IPTV系统中的架构、媒体服务器的数据以及接口功能,无需增加额外的测试仪器或设备,并且对IPTV业务网络改动小,部署方便。显然,本领域的技术人员应该明白,上述的本发明的各模块或各步骤可以用通用的计算装置来实现,它们可以集中在单个的计算装置上,或者分布在多个计算装置所组成的网络上,可选地,它们可以用计算装置可执行的程序代码来实现,从而可以将它们存储在存储装置中由计算装置来执行,或者将它们分别制作成各个集成电路模块,或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样,本发明不限制于任何特定的硬件和软件结合。以上所述仅为本发明的优选实施例而已,并不用于限制本发明,对于本领域的技术人员来说,本发明可以有各种更改和变化。凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。
权利要求
1.一种故障定位方法,其特征在于包括如下步骤从机顶盒和/或预先设置在网络电视IPTV系统中的业务监控点获取IPTV业务的监控数据;根据所述监控数据中的一个或多个参数的值依照对应关系定位所发生故障,其中,所述对应关系为预先设置的参数取值与故障的发生之间的关系。
2.根据权利要求1所述的方法,其特征在于,在根据所述监控数据中的一个或多个参数的值依照对应关系定位所发生故障之前,所述方法还包括根据用户上报的信息和/或根据所述监控数据确定的平均意见得分MOS值确定发生故障。
3.根据权利要求1所述的方法,其特征在于,根据所述监控数据中的一个或多个参数的值依照所述对应关系定位所发生故障包括根据所述监控数据确定所述IPTV系统中发生所述故障的位置,和/或,确定发生所述故障的故障类型。
4.根据权利要求3所述的方法,其特征在于,确定所述故障发生在以下位置的至少之所述IPTV系统的头端、所述IPTV系统的业务平台、所述业务平台到机顶盒之间的接入网、所述机顶盒。
5.根据权利要求3或4所述的方法,其特征在于,根据所述监控数据确定所述IPTV系统中发生所述故障的位置包括根据所述监控数据判断所述故障发生的范围的大小;根据所述范围的大小确定所述IPTV系统的架构中能够对所述范围的带来影响的位置发生故障。
6.根据权利要求5所述的方法,其特征在于,在根据所述监控数据判断所述故障发生的范围的大小之前,所述方法还包括根据来自所述机顶盒的监控数据确定所述机顶盒未发生故障,以及,根据来自监控头端的业务监控点的监控数据确定来自所述头端的数据正常。
7.根据权利要求3、4、6中任一项所述的方法,其特征在于,确定所述故障的故障类型包括以下至少之一仅涉及到频道的故障、视频编码故障、承载所述IPTV的网元或者线路出现的故障。
8.根据权利要求1至4中任一项所述的方法,其特征在于,所述监控数据包括以下至少之一所述IPTV业务的服务质量信息;来自用户的平均意见得分值。
9.根据权利要求1至4中任一项所述的方法,其特征在于,从所述机顶盒获取所述监控数据包括以下至少之一所述机顶盒周期性上报所述监控数据;通过所述机顶盒上的抓包工作所抓取的数据包获取所述监控数据。
10.一种故障定位装置,其特征在于包括获取模块,用于从机顶盒和/或预先设置在IPTV系统中的业务监控点获取IPTV业务的监控数据;定位模块,用于根据所述监控数据中的一个或多个参数的值依照对应关系定位所发生故障,其中,所述对应关系为预先设置的参数取值与故障的发生之间的关系。
11.根据权利要求10所述的装置,其特征在于,所述定位模块还用于根据用户上报的信息和/或根据所述监控数据确定的平均意见得分MOS值确定发生故障。
12.根据权利要求10所述的装置,其特征在于,所述定位模块还用于根据所述监控数据确定所述IPTV系统中发生所述故障的位置,和/或,确定发生所述故障的故障类型。
13.根据权利要求12所述的装置,其特征在于,所述定位模块包括 判读模块,用于根据所述监控数据判断所述故障发生的范围的大小;确定模块,用于根据所述范围的大小确定所述IPTV系统的架构中能够对所述范围的带来影响的位置发生故障。
全文摘要
本发明公开了一种故障定位方法及装置,该方法包括,采用从机顶盒和/或预先设置在IPTV系统中的业务监控点获取IPTV业务的监控数据;根据监控数据中的一个或多个参数的值依照对应关系定位所发生故障,其中,对应关系为预先设置的参数取值与故障的发生之间的关系,通过本发明,解决了无法在IPTV系统中整体定位故障的问题,进而达到了可以在IPTV系统中进行整体的故障定位,为提高IPTV系统中故障处理效率提供了保证的效果。
文档编号H04L12/24GK102291267SQ201110273149
公开日2011年12月21日 申请日期2011年9月15日 优先权日2011年9月15日
发明者耿国庆 申请人:中兴通讯股份有限公司
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1