奉贤部落论坛创建于2006/1/18
  • 0

[转贴] 对于微信收费,三问工信部

 
发表于 2013-4-7 08:36 | 显示全部楼层 |阅读模式

看到最近网上讨论很激烈的微信收费问题,小子略感愤怒,在此发点牢骚。

本人真实姓名联系方式等随时免费提供·随时欢迎上门查水表,跨省追捕。



那个不知道是否吃有机物长大的部门,提出要微信向运营商或者用户收费的要求,理由是OTT··即Over The Top,过顶传球。他们认为互联网公司(腾讯)越过运营商,发展语音视频和数据业务。

简单的说,他们认为微信占用了运营商的带宽,同时有可能会威胁到运营商的利益。比如很多人用微信后,不再用短信,运营商的短信费就赚不到了。这就是他们提出要收费的依据。

小子在此有如下几点疑问:

1.微信用户利用WIFI或者移动运营商提供的网络,来得到微信服务。每一条微信发出或接受,都是基于手机流量或者WIFI流量的。流量是付费的,也就是说,用户已经付费购买了使用微信所占用带宽的对应服务。

我买1个月1G的流量,我用来听歌看电影,或者,发微信,这是不是我的正常权利?按工信部的逻辑,是否我听歌,看电影,看网页··所有这些音乐,电影和网站的提供者都需要给移动运营商付费?那为什么光找微信收费?

2.各种砖家学者提出,如果微信免费,会导致运营商的设备和网络,亏空运营,不合理。



针对这个问题,小子又迷茫了。上微信,众所周知,需要什么?网络!这网络哪来的?有如下途径

1)手机上网(比如2G,3G,CDMA等)

2)WIFI。 WIFI的网络来源是用户购买的宽带服务

敢问这些砖家学者,用户手机上网都是免费的么?还是用户自己家wifi的上流来源,比如ADSL等,是免费的么?用户缴纳的网络费用如果不是用来维护网络和设备,请问这钱去哪了?买茅台了?

3.一部分砖家学者还有一套理论,认为微信影响了传统短信的发展,比如彩信等,收到严重影响,故此应该收费压制。

按照此流氓理论,是否我们应该停止所有电子邮件服务,或者电子邮件全部应该收费··这样就能人们都去寄信,就不会让邮局日渐衰落?所谓市场经济,落后就该淘汰,所有新技术都是否应该停止?手机的出现直接导致花费巨大的固定电话网络大幅度衰退,是否应该禁止手机使用?或者手机打电话一分钟一万块来保证固话的发展?



最后,工信部,工信部·全名叫工业和信息化部,是指导行业发展的部门。微信是国内难得的,除了抄袭外,还有很大的创新的软件。他们提供了一种全新的交流方式。这在业界是一个了不起的发展和创新。强制要求微信收费的结果,无非就是这个软件死了。除了铁杆粉丝,大部分用户跑了。利用一个歪理去扼杀一个难能可贵的创新软件,是一个号称知道行业发展的部门该做的事情么?

综上所述,小子严重怀疑,并且觉得有必要再次唠叨一遍:工信部,请问,你们的决策人,是吃有机物长大的么?

上述为本人的观点,欢迎拍砖或找本人探讨。

一个恨铁不成钢的海外学子

2013年4月6日


楼主热帖
发表于 2013-4-7 08:45 | 显示全部楼层
较真你就输了
发表于 2013-4-7 08:50 | 显示全部楼层
认真你就输了
发表于 2013-4-7 09:03 | 显示全部楼层
听歌看电影只会增加收入运营商当然不管 巴不得你天天看 看到流量爆了。。但是微信的业务正好与他们的语音和短信业务冲突了。。用了我的网络来抢我的生意,运营商肯定不爽了
发表于 2013-4-7 09:09 | 显示全部楼层
你不觉得是联合炒作吗
再说了,本来就不用微信。
发表于 2013-4-7 09:12 | 显示全部楼层
。垄断集团厚颜无耻
发表于 2013-4-7 09:18 | 显示全部楼层
5 60岁的人了懂个p的网络
发表于 2013-4-7 09:27 | 显示全部楼层
木有微信的飘过
发表于 2013-4-7 09:34 | 显示全部楼层
看着吧, 收不了费的.
发表于 2013-4-7 10:22 | 显示全部楼层
收费就不用!没大问题!
发表于 2013-4-7 11:07 | 显示全部楼层
可笑啊,如果在国外运用微信怎么办?
发表于 2013-4-7 11:07 | 显示全部楼层
可笑啊,如果在国外运用微信怎么办?
发表于 2013-4-7 11:07 | 显示全部楼层
可笑啊,如果在国外运用微信怎么办?
发表于 2013-4-7 13:03 | 显示全部楼层
砖家研究的就是 怎么样去收费  各种理由
发表于 2013-4-7 22:38 | 显示全部楼层
什么是微信呀
发表于 2013-4-8 00:17 | 显示全部楼层
收费立马删'本来就不怎么用
发表于 2013-4-8 07:13 | 显示全部楼层
fengxianjun 发表于 2013-4-7 22:38
什么是微信呀

约什么用的
发表于 2013-4-8 19:40 | 显示全部楼层
近日,微信将收费的说法在网上盛传,引发了很多争议,多数网友的观点是“我已经支付了流量费用,用这些流量玩什么应用是我的自由,凭什么重复收费?” 网上的意见领袖也纷纷表态反对,甚至搞了个是否支持收费的投票,反对者占96%以上,这个悬殊结果很正常,若搞个是否支持公社食堂收费的投票,绝大多数社员也会投反对票的。不过,这场争论从开头就把目标搞错了,微信收费指的是运行商向腾讯公司收费,而不是向用户收费,属企业间的合作成本分担与利益再分配,欧洲早有私有运营商向谷歌、苹果收费的先例,这是正常商业行为,腾讯公司可将成本转嫁给广告商,用户仍可以免费使用手机微信。

    清楚了运营商是向腾讯公司而不是向个人用户收费后,仍有人担心腾讯公司会不会把成本转嫁给用户,这就完全取决于腾讯公司的营销策略了。如果把手机微信的运行成本让运营商担负,那它会不会把成本转嫁给用户呢?例如全面提高流量费?公众反对运营商向腾讯公司收费,结果自己却被迫给运营商多交了钱,这恐怕就是南辕北辙了吧。

    那运营商向腾讯公司收费是否合理呢?怎样才能更加保证用户的利益?这要从技术角度说起,简单而言,手机网络采用的是基于无线通信的电信技术构架,而微信诞生于基于计算机网络的互联网技术构架,这两种构架是非常不同的,融合起来有很多困难。构架的不同并不是人为设置的技术壁垒,而是环境等客观因素所决定的。例如手机信号是无线的,频带资源相比基于光纤的计算机网络而言稀缺的多,无线信号所受到空中干扰大衰减快,需要配置密集的基站,而基站的成本远比计算机网络的中继站高得多。类似的不同还有很多,总之一句话:相同的应用,跑在手机上要比跑在台式机上要贵得多,这是客观现实。

    QQ和微信等即时通信应用有个特点,个把分钟就要向网络推送下状态信息,可供你的好友查看你是否在线等等,对于基于光纤的计算机网络而言,支撑这种周期性的心跳信号很容易,但对于基于无线通信的手机网络就非常不同了。手机从待机状态调整为与基站通信状态,有着非常繁琐的过程,单说联络上后基站发出调整手机功率的信号,就要上百次之多,微信周期性的心跳信号会给手机网络带来很大的负担。@拐-五洞 网友为此打了一个很通俗的比方:每个装了微信客户端的手机用户好比是KTV的顾客,频繁喊服务员,每次都要加粒爆米花。要是每次喊服务员加一瓶啤酒就罢了,要是只有几个包房碰上这样顾客也就罢了,微信相当于N多顾客都这么干,服务员跑得团团转,对这种顾客肿么办?

    百万手机用户的城市,有10万信道就足够了,用户随意使用手机,但同时有10万个以上用户使用的概率极小,基本不用考虑这种极端情况,遇到高密集人群集会时增派机动式基站车就能解决问题。少量信道可支撑更多用户,全世界运用商的规划都是基于这种概率分析而制定的。但若保证百万手机用户同时微信在线,那就要再增设90万信道,手机网络受到了与其架构完全不同的互联网应用的严重挑战。

    运营商铺线缆、架基站、建机房,然后通过收取通话费、短信费、流量费来赢利,好比盖了一家剧场,装修花了不少钱,为吸引客源而定了低门票价,但里面的矿泉水卖20以弥补建设运营成本并最终赢利,但挎篮小贩买了一张门票进来后不去消费,反而做起了生意,他的矿泉水卖5块,由于没有硬件成本负担,他的利润反而更高,当然更受顾客的欢迎,但最终结果就是剧场关门大吉,大家都没得玩。若是允许KTV老板向小贩收点进场费,甚至放弃小吃饮料的经营,将之承包给更有经验的小贩,这可能会迎来三赢的局面。

    从发展趋势来看,运营商会越来越集中于做“智能管道”,即更加专注于无线通信网络的建设,原来经营的面向用户的通信业务会更多地让互联网商接手,互联网商当然要为运营商的基础建设而支付使用费用,然后通过竞争而给用户提供更加优质和廉价的服务。但由于技术构架融合的复杂性,面向无线互联网的智能管道建设还有一段路要走,这不仅是中国的问题,也是全世界的问题,用户要有耐心,而且不能被“免费”的噱头所误导,无论是运营商还是互联网商,没有一家是活雷锋,天下没有免费的午餐,羊毛也总是出自羊身上的。

注:作者系通信专业博士,高校副教授,与运营商无直接关系,有体面的阳光收入和稿费进项,不是任何商家的枪手。
发表于 2013-4-8 20:32 | 显示全部楼层
运营商问马化腾收钱,又不是问你收钱,鸡动什么
发表于 2013-4-8 20:57 | 显示全部楼层
微信神器~~~~
您需要登录后才可以回帖 登录 | 注册

Archiver|手机版|小黑屋|关于我们

Copyright © 2001-2024, Tencent Cloud.    Powered by Discuz! X3.5

奉贤部落论坛创建于2006/1/18. 已经运行: 举报投诉邮箱:skyyw@52fx.cn

GMT+8, 2024-12-22 21:45 , Processed in 0.097400 second(s), 10 queries , Gzip On, Redis On.