以下是引用网络飞鱼在2004-8-25 10:02:00的发言:
这个东东目前最大的痛苦就是测试设备的价格高高在上,如果能够作个低成本的也还可以。电信、网通在招标的时候明确要求DSLAM厂商提供测试功能,但是高昂的价格又迫使不得不在实际的采购当中放弃了
楼上的老兄说的对,永远不要从技术的角度去分析市场
小灵通就是一个很典型的例子
以下是引用一纸空文在2004-11-10 16:21:00的发言:
也来凑凑热闹:--------------->
【对宽带运维系统的三点看法】
1. 宽带运维能够发现的线路或者应用问题的范围是什么?
要解决问题第一步首先是发现问题, 无论是由于配置错误还是由于线路固有问题造成的问题, 宽带运维能够发现的只有很小的一部分,而且即使把详细的线路信息的测试结果给你你也不一定能够判断出问题的所在,从用户端开始分析:PVC配置错误,桥接、路由设置错误, VCMux,LLC封装设置错误, 用户端分离器电话FAX安装位置错误,分线盒接触不良,端线进水,交接箱接触点老化,支线绝缘问题造成的搭接,长期浸水造成的对地阻抗下降, 管线交叉点处的集中干扰,MDF处接触问题,中心局和远端局线径不一致引起的阻抗匹配和反射,工程队为了节省而新采用的大部分扭距严重不符合规范的线缆,MDF跳线时线路损伤。。。。这一堆问题,宽带运维系统能够检测出的没有几个
二 . 我们能够从宽带运维中获得信息是什么?
一般来说,借助于抓线矩阵以及CableShark对线路的分析, 我们能够获得窄带12项的测试结果,这12项参数大致上只能查处线路的通断以及开短路情况,还能获得TDR和部分频段的FDR结果,这个结果需要专业的分析才能够获取线路对于DSL信号的传输特性,而目前一般的维护人员很难有这种专业分析能力,我们还能获得类似噪声,衰减等曲线,这个是最重要的,但是我敢保证,能够从这个曲线去计算比特分配图以及增益表的人没有几个,其次通过ATUC以及ATUR仿真能够排查C端和R端的故障点,仅仅是排查而已,但是你能具体判断出实际上C端和R端具体的故障原因吗?最后,还有一个纵向平衡测试的结果,但是又有几个人理解纵向平衡的真正含义?至于说桥接抽头和加感线圈,这个在中国目前的实际的线路中几乎不存在,即使存在,也是在用户家里的抽头,根据反射信号的特点和计算,这种反射不会构成什么影响。
对于MODEM的诊断,各个厂家都有一个远程管理解决方案,目前看来, 通过EOC Channel(ADSL2、2+中通称为 OverHead Message Channel)获得大多数支持但是并不能赋予实际的应用,因为这个Channel最大也就20kbps (记住是k bit per second),传十个字节都要等好几秒, VC的方式虽然被主流唾弃,但是这是唯一能够简化应用的方案,一条专用的Pvc并不带来额外的负担,速率又快,比较现实,但是最好十两者能够结合,可以看看Modem中的一些配置,可以解决一些问题,但是,这需要对Modem进行升级,试想一下,为了一个宽带运维,对现在的两千多万用户端进行升级,合理吗?现实吗?
三. 宽带运维最好的解决方案是什么?
宽带运维是叫得好听,其实并不能解决啥问题。比较现实的一种方案是套片内置测试功能,即不用抓线矩阵,也不用CableShark分析仪,不用进行现网改造。只要线卡支持Selt, Delt,DMT测试,我个人觉得就够了,目前业界这样的套片已经出现了,SELT能够同时进行TDR,FDR测试,返回测试结果,能够应用4.5dkm到5Km,随着技术的进一步发展,两个月之后应该能够测试6Km到6.7Km.而且FDR分析的结果比较理想;ADSL2、2+中提到的DELT,一个标准的测试应用, 目前能够在6Km范围内提供准确的分析结果,比CableShark的结果更能说明问题,但是美中不足的是必须和ADSL2/2+的CPE配合使用
相信运营商的头脑是清醒的,为了一个宽带运维的鸡肋多花多少银子,在利润日渐消瘦的今天,多少是有一些风险的。宽带运维是设备供应商的利润增长点,但是对运营商则是极为不利的,相反,强调用户板本身的功能,这个才是根本出路。不仅现实而且符合中国国情。
通信人家园 (https://www.txrjy.com/) | Powered by C114 |