移动计费每分钟按多少秒算
编辑: 成考报名 发布时间：01-21 阅读：
移动计费每分钟按多少秒算篇一
《建议移动电话实行按秒计费》
全国人大代表夏绩恩:建议移动电话实行按秒计费全国人大代表、四川眉山市政协常委、农工党眉山市总支主委夏绩恩3月4日说，近年来，移动电话通话不足1分钟按1分钟计费的霸王模式，不仅越来越受到广大人民群众的质疑，同时数以亿计的移动电话使用者对此亦“深恶痛绝”且颇有微辞。 夏绩恩认为，市场交易行为主要应当体现在“诚信、公平、合理”和“童叟无欺”的基础上，人们在日常实际生活中对于交易过程中存在的“零头”现象，往往遵循公认的颇为人们普遍接受的“四舍五入”约定成俗交易法则。而往往也只有寡头垄断市场中的“垄断企业”敢对“诚信、公平、合理”原则和“四舍五入”交易法则于不顾。移动电话通话不足1分钟按1分钟计算的计费模式就是典型的违反《价格法》、《消费者权益保护法》、《政府制定价格听证办法》和《电信条例》等法律法规的寡头垄断例证。 移动电话通话不足1分钟按1分钟计费的模式是否诚信、公平、合理；是否存在价格欺诈和乱收费？夏绩恩说：“应当让事实说明一切。” 据夏绩恩调查分析 理论上讲假设有59人分别在目前移动通信计费模式下分别实际通话1秒、2秒、3秒……59秒就相应被多计费59秒、58秒、57秒……1秒，总计起来59人实际通话1770秒则被实际计费3540秒、多计费部分占实际通话时长的50%，也就是说移动通信营运商在为消费者只实际提供了1770秒电信服务的情况下则可以强势、霸王地多收取了50%的移动电话通信服务费用。 通过实际随机抽查某人不同年段的两个月内移动通话分别为381次和634次、通话实际时长分别为737分钟和1188分钟,两段通话中分别有1次和3次为整分钟通话时长完毕未见多计费外，其他380次和631次通话均有不足一分钟按一分钟计费的情况，最多一次被多计费59秒、最少一次被多计费1秒；实际分别被多计费180分钟和350分钟、平均每通话一次分别被多计费28.42秒和33.38秒；两个月多计费部分分别占实际通话时长的24.42%和29.42%；也就是说移动通信营运商在为消费者只实际提供了737分钟和1188分钟电信服务的情况下确可以根据“霸王条款”的计费模式强势地多收取24.42%和29.42%的电信服务费用。同时，根据实际计算通话次数越多被多计费的概率则成上升趋势。 夏绩恩还算了一笔账 中国三大移动电话营运商2010年年报显示共实现营业收入为8763.64亿元、其中实现移动通信收入4638.82亿元。若按照每通话时长至少被多计费24.42%计算，2010年三大营运商以“不足一分钟按一分钟计费的计费模式”多计费并且相应增加了移动通信收入1132.
8亿元，2010年全国移动用户有8.63亿，平均每个移动通信用户每年被不合理的计费模式多计收通信服务费用131.26元。 种种迹象表明：三大移动电话营运商以垄断市场行为而确定的移动电话以分钟为最小计价单位的模式是完全违反《价格法》“遵循公平、合法和诚实信用的原则”和《消费者权益保护法》“遵循自愿、平等、公平、诚实信用的原则”的违法行为，而且是有失公允并应当受到价格法处罚的一种乱收费行为。同时，不足一分钟按一分钟计费的模式是典型的“霸王条款”其侵占消费者的话费不是小事情，而是关系到广大消费者权益是否能够得到保护的大问题。对于这种严重损害消费者权益的大是大非问题，政府及发改委、工信部和工商等相关职能部门不应该再继续保持沉默而应当及时出面干预且应当有所作为、并敢对垄断说不！切实保护或维护消费者的合法权益。 目前我国现行实行的移动通信业务“不足一分钟按一分钟的计费”模式存在的主要问题：1.是明显是违反《反垄断》、《价格法》、《消费者权益保护法》、《政府制定价格听证办法》和《电信条例》等有关基本规定并且应当受到相关法律追究的违法行为；2.是中国移动通信三大营运商不劳而获、座收利润的重要渠道；3.是彻头彻尾的不合理的“垄断”霸王条款；4.不仅存在价格欺诈同时亦是乱收费的噱头；5.是完全违反《价格法》第七条“经营者定价，应当遵循公平、合法和诚实信用的原则”的规定且有失公允的行为。 为此，夏绩恩建议： 一、尽快取消目前不合理的按分计费模式或对其进行“反垄断”调查与处罚。 发改委、工信部等部门应当对违反“诚信、公平、合理”原则的不足一分钟按一分钟计费的垄断霸王计费模式予以清理和取消，还消费者一个“公平、平等和诚实信用”的消费环境。“反垄断”任重而道远不仅是政府的责任、更期待此项工作能够善始而善终；同时不仅冀希望各相关部门切实维护市场公平，不仅需要反垄断实现充分市场化，更需要深化体制改革作为支撑并切实加强对垄断行业的监管。而且高需要相关部门根据《价格法》和《消费者权益保护法》等规定对三大营运商违法行为进行处罚以儆效尤。 二、尽快实施合理、公平和诚信的按秒计费或“四舍五入”计费模式。 工信部、发改委（价格）等有关部门应当以人为本、尊重民意，在切实取消目前计费模式的基础上尽快（按照技术、设备等难易程度）选择实行：①.实行全新的以按秒计费的模式；②.完善按分计费的模式引入“四舍五入”计费交易法则（不
足30秒不计费，超过30秒按一分钟计费），使广大消费者明明白白消费，亦使经营者诚实服务、摒弃不合理、不诚信和不道德的垄断经营模式。 三、尽快实施电信服务收费项目价格听证。 国资委副主任邵宁在“2011中国企业领袖年会”上发言透露：“包括石油石化、电网、通信服务等领域的企业均属于公益型国企”。所以，电信服务收费理当属于《价格法》第十八条所涉及的“自然垄断经营”或“重要的公益性服务”等政府定价行为的范畴，其服务收费方式和服务价格亦应当纳入实行政府定价或政府指导价范畴。工信、发改委、工商等部门应当认真履行管理职责，各司其职、各负其责协调配合决不允许越俎代庖，并严格执行《价格法》和《政府制定价格听证办法》的有关规定举行公开听证，并最后经过定价机关作出定价决定后方可执行。同时，对违反《价格法》、《消费者权益保护法》、《反垄断》和《政府制定价格听证办法》的行为应当严肃追究相关责任人的法律责任。★
移动计费每分钟按多少秒算篇二
《移动计费系统解题思路》
解题思路
数据分析与统一计算公式： 分析本系统的业务，可以看到普通用户和VIP用户在订购套餐的方式以及月底计算账单的公式上都有很大的不同：
（1）普通用户没有月租费和月基本费、而VIP用户有月租费或月基本费。
（2）普通用户是单独订购电话、短信和数据套餐，每项套餐单独收取月功能费；VIP用户不能单独订购电话、短信和数据套餐，VIP用户订购的套餐中同时包含了电话、短信和数据等服务功能。
我们可以为普通用户和VIP用户分别设计出一个月底计算账单的公式，但是，为了简化编程，我们也可以为两种不同用户设计出一个统一的月底计算账单的公式，这就好比“大象有尾巴，而蚂蚁没有尾巴，大象没有触角，而蚂蚁则有触角，能否用同一个累加所有器官的公式来计算蚂蚁和大象的体重呢？当然可以，这时候只需要假设蚂蚁也有尾巴，只是蚂蚁的尾巴重量为0，假设大象也有触角，只是大象触角的重量为0，这样，就可以用同一种累加所有器官的公式来计算蚂蚁和大象的体重了。”我们可以采用如下方式来统一各类用户在各种情况下的费用计算公式：
（1） 月基本费或月租费：月基本费方式为固定值，月租费方式为当月总天数*每天费用或者（当月总天数-入网日+1）*每天费用，只有vip用户才存在此项费用，但是为了统一计算公式，可以认为普通用户也有此项费用，值为0。
（2） 电话收费时长：等于(电话时长-免费时长)，计算后的值小于0则记为0，免费时长又分为两类：新入网的免费和套餐中的免费，新入网的免费在用户对象中处理，套餐中的免费封装在套餐策略对象中处理。
（3） 电话、短信、数据套餐月功能费：只有普通用户定了套餐才有此项费用，但是为了统一计算公式，可以认为没定此功能套餐的普通用户和vip用户也有此项费用，值为0。
（4） 月电话费用=电话套餐月功能费+单位计费价格*电话收费时长
（5） 按月电话费用的相同规则计算月短信费用和月数据费用
（6） 月总计费用=月基本费或月租费 + 月电话费用 + 月短信费用 + 月数据费用 我们可以用如下一幅“月账单费用的组成成分”图来直观地理解上面的计算公式：
采用一种便于程序代码读取的格式在配置文件中存储各项数据
刚开始猛然看到这么多数据项，肯定会感觉纷繁杂乱，理不出头绪来，但是，不管这些数据项有多么多，归结起来，不就是某个用户要使用自己的某种数据吗？只是不同的用户有不同的数据罢了，每个用户只需要关心和使用自己的数据、而不用关心其他用户的数据就显得简单多了，因此可以写一个类来专门读取用户的数据，在配置文件中存储的各项数据应想办法采用一种便于该类读取的格式。
（1） 要存储的数据项有：功能单价费用、功能套餐免费数量、功能套餐月费用、新入网免费数量、整体月基本费或月租费。
（2） 一些数据还要随以下类型进行区分：用户类型、套餐类型、功能类型。
（3） 在配置文件中通过用点（.）对数据项名称进行分级的方式来区分各个数据项所属的类别和功能，如下所示：
common.normal.phone.price --> 表示普通用户/非套餐/电话/单价
common.pack1.phone.price --> 表示普通用户/套餐/电话/单价
common.pack1.phone.free --> 表示普通用户/套餐/电话/免费数量
common.pack1.phone.rent ?表示普通用户/套餐/电话/套餐月功能费用
vip.normal.phone.price --> 表示VIP用户/非套餐/电话/单价
vip.pack1.phone.price --> 表示VIP用户/套餐1/电话/单价
vip.pack2.phone.price --> 表示VIP用户/套餐2/电话/单价
common.new.phone.free --> 表示普通用户/新开户/电话/免费数量
vip.new.phone.free --> 表示VIP用户/新开户/电话/免费数量
（4） 对于值为0的数据项，不用在配置文件中存储，这样，当程序代码从配置文件中没有读取到该数据项时，即认为该值为0。
（5） 对于vip用户的整体月基本费或月租费，由于计费单位不一样，采用配置文件方式存储将增加程序的复杂度，所以，决定直接在程序代码中硬编码。
为了便于程序编写，在配置文件中要注意如下两点：
（1） 由于程序中要求每次传输的数据量都是10k的整数倍，因此可以将数据通信费的单价单位由M转换成K表示，由于数据通信费的价格5元/M，转换后则是0.5分/K，这样程序中就涉及到小数处理了。由于在程序中处理小数是很繁琐和容易出现误差的事情，所以，最好还是想办法先统一转换成整数形式进行处理，由于数据传输量都是10k的整数倍，因此，想到将数据通信费的价格5元/M转换成5分/10K。因此，在配置文件中将所有的价格和费用的计量单位由元转换成分表示。
（2） 后来在配置文件中填写各项数据时，发现VIP用户订购套餐2时的数据费仅为0.5元/M，这时候转换的结果是0.5分/10k，又还是出现了小数，故想到把计费单位转成5厘/10k，所以，在配置文件中最终还是应将所有的价格和费用的计量单位由元转换成厘进行计费。 按照上面这些思想设计和编写出来的配置文件conf.properties的完整内容如下：
[c-sharp] view plaincopy 1. common.normal.phone.price=600
2. common.normal.message.price=100
3. common.normal.data.price=50
4.
5. common.pack1.phone.price=500
6. common.pack1.message.price=100
7. common.pack1.data.price=30
8. common.pack1.phone.rent=20000
9. common.pack1.message.rent=10000
10. common.pack1.data.rent=20000
11. common.pack1.phone.free=60
12. common.pack1.message.free=200
13. common.pack1.data.free=5000
14.
15. vip.normal.phone.price=400
16. vip.normal.message.price=100
17. vip.normal.data.price=30
18.
19. vip.pack1.phone.price=300
20. vip.pack1.message.price=100
21. vip.pack1.data.price=10
22. vip.pack1.phone.free=750
23. vip.pack1.message.free=200
24. vip.pack1.data.free=10000 25.
26. vip.pack2.phone.price=200
27. vip.pack2.message.price=100
28. vip.pack2.data.price=5
29. vip.pack2.phone.free=2000
30. vip.pack2.message.free=500
31. vip.pack2.data.free=30000
32.
33. common.new.phone.free=60
34. common.new.message.free=200
35. common.new.data.free=5000
36.
37. vip.new.phone.free=200
38. vip.new.message.free=200
39. vip.new.data.free=10000
接着可编写一个读取上面的配置文件中的各项数据的ConfigManager类，该类根据用户类型、套餐类型、业务功能类别来读取相应功能套餐的单价、免费数量、功能费，以及新用户免费数量。源码如下：
[c-sharp] view plaincopy 1. public class ConfigManager {
2. private static Properties config = new Properties();
3. static{
4. InputStream ips = ConfigManager.class.getResourceAsStream("/conf.pro
perties");
5. try {
6. config.load(ips);
7. } catch (IOException e) {
8. throw new ExceptionInInitializerError(e);
9. }
10. }
11.
12. private static String makePrefix(int customerType,int packType,int busin
essType){
13. String customerTitle = customerType==0?"common":"vip";
14. String packTitle = packType==0?"normal":("pack"+packType);
15. String businessTitle = businessType==0?"phone":businessType==1?"mess
age":"data";
16. return customerTitle + "." + packTitle + "." + businessTitle;
17. }
18.
19. private static int getNumber(String key){
20. String value = config.getProperty(key);
21. try{
22. return Integer.parseInt(value);
23. }catch(Exception e){
24. return 0;
25. }
26. }
27.
28. public static int getPrice(int customerType,int packType,int businessTyp
e){
29. return getNumber(makePrefix(customerType,packType,businessType)+".pr
ice");
30. }
31.
32. public static int getFree(int customerType,int packType,int businessType
){
33. return getNumber(makePrefix(customerType,packType,businessType)+".fr
ee");
34. }
35.
36. public static int getRent(int customerType,int packType,int businessType
){
37. return getNumber(makePrefix(customerType,packType,businessType)+".re
nt");
38. }
39.
40. public static int getNewCustomerFree(int customerType,int businessType){
41. String[] businesses = {"phone","message","data"};
42. return getNumber((customerType==0?"common":"vip")+".new." + business
es[businessType] + ".free");
43. }
44. }
面向对象的分析和设计：
在进行面向对象设计之前，必须具备和把握了一个重要的经验：谁拥有数据，谁就对外提供操作这些数据的方法。大家可能会说，刚开始看到需求时，只知道某一个用户要使用很多各
移动计费每分钟按多少秒算篇三
《移动计费系统》
移动计费每分钟按多少秒算篇四
《移动计费系统》
Version 1.0
新一代电信计费系统
软件需求说明书
文挡编号
WD_visitor_ZZU_100318 可行性研究报告 *** ***
2010-3-18
文挡名称
撰写人 审核/批准 创建时间
版本变更说明：
1引言 ............................................................................................................................................... 4 1.1编写目的 ................................................................................................................................. 4 1.2背景......................................................................................................................................... 4 1.3定义......................................................................................................................................... 4 1.4参考资料 ................................................................................................................................. 5 2任务概述 ....................................................................................................................................... 5 2.1目标......................................................................................................................................... 5 2.2用户的特点 ............................................................................................................................. 5 2.3假定和约束 ............................................................................................................................. 6 2.3.1开发期限 ........................................................................................................................ 6 2.3.2开发环境 ........................................................................................................................ 6 2.3.3协议 ................................................................................................................................ 6 2.3.4技术 ................................................................................................................................ 6 3需求规定 ....................................................................................................................................... 7 3.1对功能的规定 ......................................................................................................................... 7 3.2对性能的规定 ....................................................................................................................... 16 3.2.1精度 ................................................................................................................................ 16 3.2.2时间特性要求 ................................................................................................................ 16 3.2.3灵活性 ............................................................................................................................ 16 3.3输人输出要求 ....................................................................................................................... 16 3.4数据管理能力要求 ............................................................................................................... 17 3.5故障处理要求 ....................................................................................................................... 17 3.6其他专门要求 ....................................................................................................................... 18 4运行环境规定 ............................................................................................................................. 18 4.1设备....................................................................................................................................... 18 4.2支持软件 ............................................................................................................................... 18 4.3接口....................................................................................................................................... 19 4.4控制....................................................................................................................................... 19
软件需求说明书
1引言
1.1编写目的
这编写本说明书的目的在于明确“新一代电信计费系统”的开发者对该系统的需求，明确系统需要实现的具体功能，系统适合运行所需的相应软硬环境，系统数据的输入输出要求，为系统数据库结构设计、编码实现以及测试人员提供基础的指导。
本说明书的预期读者为：“新一代电信计费系统”系统的使用者和开发者。
1.2背景
a． 待开发的软件系统的名称：新一代电信计费系统 b． 本项目的任务提出者：visitor开发团队
开发者：visitor开发团队
用户：初步定为中国移动网络供应商及移动通信用户（主要为手机用户）实现该软件基于B/S网络
c． 该软件系统同其他系统或其他机构的基本的相互来往关系。
1.3定义
[专门术语]：客户信息包含：①个人信息：姓名，身份证号，住址。
②业务信息：账号（即手机号），使用套餐名称，客服密码，
已开业务。
HTTP的全称是超文本传输协议Hypertext Transfer Protocol。 HTTP是一个客户端和服务器端请求和应答的标准（TCP）。 客户端是终端用户，服务器端是网站。通过使用Web浏览器、网络爬虫或者其它的工具， 客户端发起一个到服务器上指定端口（默认端口为80）的HTTP请求。（我们称这个客户端）叫用户代理（user agent）。
应答的服务器上存储着（一些）资源，比如HTML文件和图像。（我们称）这个应答服务器为源服务器（origin server）。
在用户代理和源服务器中间可能存在多个中间层，比如代理，网关，或者隧道（tunnels）。 尽管TCP/IP协议是互联网上最流行的应用，HTTP协议并没有规定必须使用它和（基于）
它支持的层。
事实上，HTTP可以在任何其他互联网协议上，或者在其他网络上实现。HTTP只假定（其下层协议提供）可靠的传输，
任何能够提供这种保证的协议都可以被其使用。
SIP( 会话初始协议)的开发目的是用来帮助提供跨越因特网的高级电话业务。因特网电话（IP电话）正在向一种正式的商业电话模式演进，SIP就是用来确保这种演进实现而需要的NGN（下一代网络）系列协议中重要的一员。
SMS（Short Messaging Service） SMS（Short Messaging Service）是最早的短消息业务，也是现在普及率最高的一种短消息业务。目前，这种短消息的长度被限定在140字节之内，这些字节可以是文本的。SMS以简单方便的使用功能受到大众的欢迎，却始终是属于第一代的无线数据服务，在内容和应用方面存在技术标准的限制。 短消息服务器使移动电话（包括 Pocket PC Phone）能够使用 GSM 网络发送短消息，它具有许多有趣的功能： 一个 SMS 消息最长可包括 160 个字符。
1.4参考资料
本项目的经核准的计划任务书或合同、上级机关的批文； 中国移动资费制度 相关通信法律法规 《个人隐私保护法》
2任务概述
2.1目标
该软件的诞生是顺应时代发展的需要。中国通信制度急需改革，实名制的出现是一个趋势。这将减少以信息和移动电话为工具的诈骗及其他违法行为。
定义“新一代电信计费系统”要实现哪些功能，以及这些功能实现时的具体逻辑，为设计作指导。
2.2用户的特点
本软件的用户有两种。
第一种是网络供应商的用户，也即该系统的普通用户。他们将通过浏览器的形式进行个人信息的管理，以及了解最新的活动。他们不需要过多的计算机知识，只要能够使用Internet浏览器就行。
移动计费每分钟按多少秒算篇五
《移动计费系统》
前面的两篇博文写到：有两名同学出去面试，招聘单位分别给他们两个小项目拿回家做，三天内做出来即可给到7k以上的月薪，我都帮他们做了，详情参看《交通灯管理系统》和《银行业务调度系统》的介绍。
不久，又有一名学员给我打电话，让我帮他做一道类似的题目，不过，这次项目变成了“移动用户资费统计系统”，再细问，知道这次的招聘公司不是软通动力了，而是联想利泰，这两家公司提供的word文档格式都完全一样，我奇怪现在的软件公司怎么都学会用这招来考核求职者了，我真怀疑这些题目出自同一人之手，难道是软通动力的技术经理跳槽到联想利泰啦？他的这招面试手法确实够高！
我看到“移动用户资费统计系统”的需求文档后，发现这个系统的业务比《交通灯管理系统》和《银行业务调度系统》的业务都要复杂得多，一时间真不知道该从哪里着手， 只能回复那名学员：“这个项目题好像不是一两天就能搞定的事情，我努力做做，别抱太大希望”。如果说“交通灯管理系统”或“银行业务调度系统”做出来就可以拿到7k月薪的工资的话，我认为这个“移动用户资费统计系统”做出来的话，起码应该可以拿到1w以上的月薪。我按照“移动用户资费统计系统”的需求文档认认真真地做了两天，体力透支很大，加之十几年的编程生涯，我一直处于亚健康状态，这个“移动用户资费统计系统”终究成了压倒骆驼的最后一根稻草，我累得病倒了！等到身体康复后，我不甘心事情只做了一半就放弃了，接着又花了两天的时间，总算把这个项目题给做完了，结果又再次累病倒了。
后来又有好几名去联想利泰面试的学员拿着这个《移动用户资费统计系统》找我，我每次都把源代码给了这些学员，并讲解清楚了其中的代码结构，后来问这些学员，他们一个也没被录取，他们一致认为该公司可能只是想找个人来向他们讲解如何实现此系统的代码，看来着实枉费了我一番心机和功夫！最近，又接到多名学员的反馈，除了联想利泰，美国阿格雅技术有限公司也在使用此题目考核面试者，这个题目虽然没有华丽的外表，但它确实是一个有技术含量的项目，绝非是一个普普通通的程序员容易做出来的东西！这道题目是在解决实实在在的复杂业务问题，其中涵盖了技术含量极高的编程技巧和设计手法，这才是真正做高级项目所要学习的知识，对于广大程序员来说，它是一个不错的案例，不同于那种只是大量重复性工作的增删改查项目。
特别说明： 由于电信和银行实际环境的复杂性和产品一旦上线运行后对错误的容忍度几乎为0，电信和银行的项目在做完后都不能直接上线测试运行，而是要通过编写非常完全和严格的模拟程序来进行测试，确保万无一失后再实际上线运行，所以，为电信和银行项目编写模拟程序和比对检查程序运行的结果就非常重要了。虽然我写完了《移动用户资费统计系统》的代码，但不能保证最终的运行结果就没有错误，这需要仔细分析和比对运行结果才能发现问题，由于《移动用户资费统计系统》的业务逻辑实在有点复杂，仅凭我个人之力，实在难以比对出每个细节，为此，我专门编写了《测试用例编写指导书》和《比对检验指导书》，供感兴趣的网友参考。如果有哪位网友发现我写的程序统计出来的结果有问题，请来信详细告知，我将不胜感激。
下面是”移动用户资费统计系统“的需求：
移动用户资费统计系统
原始需求文档下载 讲座ppt下载 讲座源码下载 讲座视频下载(待补充)
模拟实现简易的移动用户资费统计系统逻辑，具体需求如下：
移动运营商A设置两种类型的用户：普通用户及VIP用户，现该运营商已有5个VIP用户和15个普通用户，共计20个用户。
普通用户资费标准如下（不考虑漫游和长途）：
【基准资费】
无月租费用。
通话费：0.6元/ 分钟（仅拨打收费，接听免费）
短信费：0.1元/ 条
数据费：5元/ M
【优惠套餐】
话费套餐：月功能费20元，最多可拨打60分钟电话，超出时间按照0.5元/分钟计费。
短信套餐：月功能费10元，最多可发送200条短信，超出条数按照0.1元/条计费。
数据套餐：月功能费20元，最多可获50M的流量，超出流量按照3元/M 计费。
注：用户可以选择多种套餐，各功能(通话、短信、数据)计费时，如已选择对应套餐，则按套餐标准计费；如未选择对应套餐，则按对应的基准资费计费。
VIP用户资费标准如下（不考虑漫游和长途）：
【基准资费】
月租费用：按天收取，2元/ 天
通话费：0.4元/ 分钟（仅拨打收费，接听免费）
短信费：0.1元/ 条
数据费：3元/ M
【优惠套餐】
套餐1 ：月基本费用100元（无月租费用），提供如下服务：
①最多可拨打750分钟电话，超出部分按照0.3元/ 分钟计费。
②最多可发送200条短信，超出条数按照0.1元/ 条计费。
③最多可获得100M数据流量，超出流量按照1元/ M计费。
套餐2 ：月基本费用200元（无月租费用），提供如下服务：
①最多可拨打2000分钟电话，超出部分按照0.2元/ 分钟计费。
②最多可发送500条短信，超出条数按照0.1元/ 条计费。
③最多可获得300M数据流量，超出流量按照0.5元/ M计费。
注：用户最多只能选择一种套餐，如未选择任何套餐，则按照基准资费计费。
各类型用户只能选择提供给本类型用户的套餐。
新用户入网。
①对于新入网的普通用户，入网当月赠送如下服务：免费拨打60分钟
电话，免费发送200条短信，免费获得50M流量。超出赠送的部分
按照普通用户基准资费进行计费。
②对于新入网的VIP用户，入网当月赠送如下服务：免费拨打200分
钟电话，免费发送200条短信，免费获得100M数据流量。超出赠送
的部分按照VIP用户基准资费进行计费（注意：需按入网天数计算月
租费用）。
每月为用户计算一次账单，用户订制的套餐信息和账单信息采用文件方式进行存储（提示：可使用java中的Properties API进行文件操作）。
用户可自由订制或退订所属用户类型的套餐，并从下月起生效。
异步随机生成客户操作如下：
①拨打电话，每次拨打时长为1至10分钟不等（随机决定，以分钟为单位）。
②发送短信，每次发送条数为1至10条不等（随机决定）。
③上网获取数据，每次获取数据流量可为50K，100K，200K，500K，1M（随机决定）。
④订制或退订相应套餐。
⑤新用户入网（随机决定用户类型）。
注：随机生成客户操作时间间隔自定，可设置。
不要求实现GUI，只考虑系统逻辑实现，可通过Log方式展现程序运行结果。
解题思路
数据分析与统一计算公式：
分析本系统的业务，可以看到普通用户和VIP用户在订购套餐的方式以及月底计算账单的公式上都有很大的不同：
（1）普通用户没有月租费和月基本费、而VIP用户有月租费或月基本费。
（2）普通用户是单独订购电话、短信和数据套餐，每项套餐单独收取月功能费；VIP用户不能单独订购电话、短信和数据套餐，VIP用户订购的套餐中同时包含了电话、短信和数据等服务功能。
我们可以为普通用户和VIP用户分别设计出一个月底计算账单的公式，但是，为了简化编程，我们也可以为两种不同用户设计出一个统一的月底计算账单的公式，这就好比“大象有尾巴，而蚂蚁没有尾巴，大象没有触角，而蚂蚁则有触角，能否用同一个累加所有器官的公式来计算蚂蚁和大象的体重呢？当然可以，这时候只需要假设蚂蚁也有尾巴，只是蚂蚁的尾巴重量为0，假设大象也有触角，只是大象触角的重量为0，这样，就可以用同一种累加所有器官的公式来计算蚂蚁和大象的体重了。”我们可以采用如下方式来统一各类用户在各种情况下的费用计算公式：
（1） 月基本费或月租费：月基本费方式为固定值，月租费方式为当月总天数*每天费用或者（当月总天数-入网日+1）*每天费用，只有vip用户才存在此项费用，但是为了统一计算公式，可以认为普通用户也有此项费用，值为0。
（2） 电话收费时长：等于(电话时长-免费时长)，计算后的值小于0则记为0，免费时长又分为两类：新入网的免费和套餐中的免费，新入网的免费在用户对象中处理，套餐中的免费封装在套餐策略对象中处理。
（3） 电话、短信、数据套餐月功能费：只有普通用户定了套餐才有此项费用，但是为了统一计算公式，可以认为没定此功能套餐的普通用户和vip用户也有此项费用，值为0。
（4） 月电话费用=电话套餐月功能费+单位计费价格*电话收费时长
（5） 按月电话费用的相同规则计算月短信费用和月数据费用
（6） 月总计费用=月基本费或月租费 + 月电话费用 + 月短信费用 + 月数据费用
我们可以用如下一幅“月账单费用的组成成分”图来直观地理解上面的计算公式：
采用一种便于程序代码读取的格式在配置文件中存储各项数据
刚开始猛然看到这么多数据项，肯定会感觉纷繁杂乱，理不出头绪来，但是，不管这些数据项有多么多，归结起来，不就是某个用户要使用自己的某种数据吗？只是不同的用户有不同的数据罢了，每个用户只需要关心和使用自己的数据、而不用关心其他用户的数据就显得简单多了，因此可以写一个类来专门读取用户的数据，在配置文件中存储的各项数据应想办法采用一种便于该类读取的格式。
（1） 要存储的数据项有：功能单价费用、功能套餐免费数量、功能套餐月费用、新入网免费数量、整体月基本费或月租费。
（2） 一些数据还要随以下类型进行区分：用户类型、套餐类型、功能类型。
（3） 在配置文件中通过用点（.）对数据项名称进行分级的方式来区分各个数据项所属的类别和功能，如下所示：
common.normal.phone.price --> 表示普通用户/非套餐/电话/单价
common.pack1.phone.price --> 表示普通用户/套餐/电话/单价
common.pack1.phone.free --> 表示普通用户/套餐/电话/免费数量
common.pack1.phone.rent ?表示普通用户/套餐/电话/套餐月功能费用
vip.normal.phone.price --> 表示VIP用户/非套餐/电话/单价
vip.pack1.phone.price --> 表示VIP用户/套餐1/电话/单价
vip.pack2.phone.price --> 表示VIP用户/套餐2/电话/单价
common.new.phone.free --> 表示普通用户/新开户/电话/免费数量
vip.new.phone.free --> 表示VIP用户/新开户/电话/免费数量
（4） 对于值为0的数据项，不用在配置文件中存储，这样，当程序代码从配置文件中没有读取到该数据项时，即认为该值为0。
（5） 对于vip用户的整体月基本费或月租费，由于计费单位不一样，采用配置文件方式存储将增加程序的复杂度，所以，决定直接在程序代码中硬编码。
为了便于程序编写，在配置文件中要注意如下两点：
（1） 由于程序中要求每次传输的数据量都是10k的整数倍，因此可以将数据通信费的单价单位由M转换成K表示，由于数据通信费的价格5元/M，转换后则是0.5分/K，这样程序中就涉及到小数处理了。由于在程序中处理小数是很繁琐和容易出现误差的事情，所以，最好还是想办法先统一转换成整数形式进行处理，由于数据传输量都是10k的整数倍，因此，想到将数据通信费的价格5元/M转换成5分/10K。因此，在配置文件中将所有的价格和费用的计量单位由元转换成分表示。
（2） 后来在配置文件中填写各项数据时，发现VIP用户订购套餐2时的数据费仅为0.5元/M，这时候转换的结果是0.5分/10k，又还是出现了小数，故想到把计费单位转成5厘/10k，所以，在配置文件中最终还是应将所有的价格和费用的计量单位由元转换成厘进行计费。
移动计费每分钟按多少秒算篇六
《中国移动应用内计费常见问题》
中国移动应用内计费常见问题
版本：V4.0
2012-9
目录
1 自测试失败检查 ............................................... 3
2 业务类问题 ................................................... 3
3 技术类问题 ................................................... 6
1 自测试失败检查
自测试过程中遇到自测试失败时，可优先参考做如下系列检查：
a) 检查网络是否可用，接入点是否cmnet或者wifi。
b) 检查paycode，appid，appkey等信息是否正确
c) 检查测试号码有没有添加测试列表
d) 检查AndroidManifest.xml 有没有添加sdk需要的权限
e) 如果是使用proguard混淆代码的，请检查cfg文件中是否有添加如下代码： -keep class com.ccit.** {*; }
-keep class ccit.** { *; }
-keep class mm.purchasesdk.**
-keep class mm.purchasesdk.** {*;}
f) 如果要在android4.0.1以上系统上正常运行此程序，目前的解决方法：armeabi，armeabi-v7a这两个文件夹仅保留一个，目前一般建议保留armeabi(这样可以兼容更多的arm架构的设备)。
g) 应用自测试不通过，总是提示支付失败，返回码214，应如何处理？
答：应用权限未配置，检查应用的AndroidManifest.xml中的权限配置是否和demo一样。 h) 自测试时应用名称和商品等信息都是显示的编码，这个是正常的吗？ 答：若是弱联网应用自测试，正常；若是强联网应用自测试，不正常。
i) 按照弱联网的标准初始化之后，支付页面提示支付成功，但是还是没有下行短信，应如何处理？
答：在自测试阶段，自测试时的订购不发生真正的扣费，无下行短信。
j) 自测试时添加的手机号在该应用商用之后，使用这个号码会产生真实扣费么？ 答：会。应用上线商用后，所有移动号码均真实扣费。
2 业务类问题
a) MM应用内计费目前支持哪些运营商？
答：暂仅支持中国移动。
b) MM应用内计费目前支持哪些平台？
答：目前SDK支持Android（1.6版以上）。
c) 是否有公共技术讨论群组和业务讨论群组？
答：开发者可安排技术人员加入应用内计费技术Q群181986362：申请前先发送：公司名称+联系人+联系电话+邮箱地址+MM应用上线数量+已在MM中上线的应用名称（提供一个即可） 到open_service@139.com成功登记后，请重新申请加入QQ交流群即可，验证信息需填写：公司全名+个人姓名。
同时可安排业务人员加入应用内计费商务Q群236946664，直接申请加入，验证信息需写明：公司全名+个人姓名。
d) 是否有开放运营合作讨论群组？
答：对开放运营感兴趣的或有意向的均可直接加入Q群：282724655。
e) 网游类应用如何接入服务器订单查询接口？
答：发送申请至公共邮箱open_service@139.com，邮件正文提供：应用ID、应用名称、企业名称、联系人、联系方式、需要配置的服务器IP地址。
f) 应用程序包是否有要求？
答：应用的程序包名（后缀为.apk）建议使用英文字符取名。
g) 无法正常登陆开发者社区，或在进行创建、提交应用及配置资源等操作时，网页展示不正常。
答：请尽量使用IE浏览器进行上述操作，或更换其他电脑尝试，同时检查贵公司网络，仍然不正常的可拨打社区客服热线400-10086-20咨询。
h) MM应用内计费目前提供哪几种计费模式？
答：“可重复购买”类、“不可重复购买”类、“租赁期”类目前对外开放，“包月”类目前统一不对外开放。
i) 我对同一个商品可以设置不同的租赁期吗？
答：在某些业务，例如杀毒软件中，主要以病毒库的更新服务作为销售的对象，这样就有可能是同一个服务因服务时长不同而卖不同的价钱。对于这种情形，在应用内商 品配置时要配置成不同的商品。
j) 场景案例：某应用中用户是花1元消费，之后将应用删除，如再次下载并面临此计费点
的时候，是否无需再次付费？
答：单次和租赁类型计费点后台保存有订购记录，重复类型不保存。即前两种计费方式不需要另行付费；后一种计费方式需要重新付费。
k) 根据现流程，在线应用上线需经过额外的评审流程，而IAP必须使用在线功能，是不是
IAP应用全都是在线应用？
答：判断应用属性是否为在线、离线的规则是根据其应用本身功能而定，IAP不改变其原属性。即离线应用不会因为使用IAP功能而被归为在线应用，因此不需要进入在线应用评审流程。
l) 已经商用的应用为什么在MM门户搜索不到？
答：该情况可能是门户搜索功能的问题，可直接向社区客服反映该情况，社区首页有联系方式 ：400-10086-20。
m) 应用可设置多少个计费点？
答：从用户体验、测试等方面考虑，单个应用计费点数量建议在6个计费点以内。 n) “应用内计费”的支付方式是怎样的？
答：是通过移动手机号码的话费进行支付的；该订购与手机号码进行绑定，通过手机号码进行身份认证。
o) 用户余额不够扣费时，IAP会做什么处理？
答：IAP正常计费，待手机充值后补扣话费。
p) 对于用户可自行选择单机或者联网的应用，在提交应用包的时候是否需要勾选联网？
答：根据应用是否需要联网做判断。不需联网，不用勾选该项；需联网，勾选该项。 q) 已经商用的应用在程序中支付的时候还是显示是自测试环境，应如何处理？
答：MM门户或者MM手机客户端下载商用包。
r) 弱联网和强联网的区别是什么？
答：弱联网：通过使用短信通道实现计费，不需要网络；强联网：需要在 wifi或GPRS网络稳定下实现计费。
s) 一个道具在不同的页面均可以购买，需要申请1个iap计费点还是要申请3个iap计费
点？
答：若道具的商品信息完全一样（如价格），申请1个计费点即可。
t) 网游是不是需要通过服务器回调来下发道具？
答：开发者自己考量，服务器接口的功能介绍可参阅《服务器接口说明书》，下载地址：
u) 应用原来接入的是计费强联网sdk，新版本能直接换成弱联网的吗？
答：支持在应用ID不变更的条件下，强联网应用直接转换为弱联网应用。
v) 弱联网的计费点是否支持不可重复购买？
答：可以申请该类型计费点。需开发者客户端自己做判断实现，SDK无法实现。 w) 请问一款应用可以同时使用计费强联网SDK和弱联网SDK么？
答：可以。建议开发者暂时不要在同一个程序包内混用强、弱两种模式的计费点。 x) 已商用的应用是否可以在原来强联网计费点的基础上，新增弱联网计费点使用吗？
答：可以。
移动计费每分钟按多少秒算篇七
《移动电话资费标准及计费方式》
移动计费每分钟按多少秒算篇八
《中国移动全国计费中心解决方案》
移动计费每分钟按多少秒算篇九
《中国移动分组域实时计费能力技术规范》
QB-╳╳-╳╳╳-╳╳╳╳
版本号：0.2.0
╳╳╳ ╳-╳╳-╳╳发布 ╳╳╳╳-╳╳-╳╳实施
中国移动通信企业标准
中国移动分组域实时计费能
力技术规范
中国移动通信有限公司 发布
目 录
1. 2. 3. 4.
范围........................................................................................................................................... 1 规范性引用文件 ....................................................................................................................... 1 术语、定义和缩略语 ............................................................................................................... 2 背景及需求分析 ....................................................................................................................... 2 4.1. 现有分组域计费概况 ................................................................................................... 2 4.2. 欠费问题根源实时计费需求分析 ............................................................................... 3 5. 分组域实时计费方案 ............................................................................................................... 4
5.1. 方案概述 ....................................................................................................................... 4 5.2. Charging Characteristics字段 ...................................................................................... 6 5.3. 分组域实时计费漫游地解决方案 ............................................................................... 7 5.4. GGSN、P-GW与BOSS之间实时计费流程 ............................................................. 7 5.4.1. 流量计费类业务实时计费流程 ............................................................................. 10 5.4.2. 时长计费类业务实时计费流程 ............................................................................. 18 5.4.3. 费率改变控制流程 ................................................................................................. 21 5.4.4. 余额不足控制流程 ................................................................................................. 22 5.4.5. 用户充值成功业务放通流程（可选） ................................................................. 25 5.4.6. 异常流程 ................................................................................................................. 26 5.4.7. PCC引入后实时计费流程 .................................................................................... 27 5.4.8. 其他流程 ................................................................................................................. 30 5.5. 设备改造及性能要求 ................................................................................................. 31 5.5.1. GGSN、P-GW功能要求 ....................................................................................... 31 5.5.2. 其他网元改造要求 ................................................................................................. 32 5.5.3. 协议接口要求 ......................................................................................................... 32 5.5.4. 物理接口要求 ......................................................................................................... 32 6. 分组域实时计费接口要求 ..................................................................................................... 32
6.1. DCC控制接口总体要求............................................................................................ 32 6.2. CCR消息格式及参数 ................................................................................................ 35 6.2.1. Service-Information参数定义 ............................................................................... 45 6.3. CCA消息格式及参数................................................................................................ 51 6.3.1. Service-Information参数定义 ............................................................................... 58 6.4. AVP Flag定义 ............................................................................................................ 59 6.5. Result-Code参数定义 ................................................................................................ 62 6.6. 其他消息格式及参数 ................................................................................................. 68 6.6.1. Re-Auth-Request/Answer Message ........................................................................ 68 6.6.2. Abort-Session-Request/Answer Message ............................................................... 71 6.6.3. Capabilities-Exchange-Request/Answer Message .................................................. 72 6.6.4. Device-Watchdog-Request/Answer Message ......................................................... 74 6.7. Disconnect-Peer-Request /Answer Message ............................................................... 74 6.8. 接口性能要求 ............................................................................................................. 75 7. 编制历史 ................................................................................................................................. 75
前 言
本标准规定了中国移动分组域实时计费能力的技术规范。
本标准主要包括：分组域实时计费能力的功能要求、流程以及接口。 本标准由中移 号文件印发。
本标准由中国移动通信有限公司技术部提出并归口。 本标准由标准归口部门负责解释。 本标准起草单位：中国移动通信研究院。 本标准主要起草人：魏彬，苑红。
1. 范围
本技术规范规定了中国移动分组域实时计费方案、实时计费接口要求，供中国移动分组域现网实施实时计费使用，适用于2G/TD网络以及LTE/EPC网络；为保证中国移动分组域网元设备支持实时计费功能的统一性、可靠性、可用性，确保业务的正常开展，特制定本技术规范。
分组域实时计费方案包括针对内容计费类业务和非内容计费类业务的实时计费方法，以及费率改变、余额不足、异常情况下的实时计费流程；实时计费接口要求包括各消息格式及参数的定义，以及接口性能要求等。另外，本技术规范也规定了漫游情况下分组域实时计费的实现方法。
分组域的实时计费对2G/TD网络的GGSN、SGSN以及LTE/EPC网络的P-GW、S-GW、MME等设备有相应的技术要求，同时需要BOSS进行相应的配合来实现，本技术规范也给出了各个网元的技术要求。
2. 规范性引用文件
序号 标准编号 [1] [2]
TS 32.299
[3] [4]
TS 29.212 TS 32.251
[5] [6] [7]
TS 29.060 RFC 3588 RFC 4006
标准名称
《省级业务运营支撑系统（BOSS）业务技术规范：实时计费分册V3.0》 Telecommunication management; Charging management; Diameter charging applications
Policy and charging control over Gx reference point
Telecommunication management; Charging management; Packet Switched (PS) domain charging GPRS Tunnelling Protocol (GTP) across the Gn and Gp interface Diameter Base Protocol Diameter Credit-Control Application
发布单位 中国移动通信有限公司 3GPP
3GPP 3GPP
3GPP IETF IETF
3. 术语、定义和缩略语
4. 背景及需求分析
4.1. 现有分组域计费概况
移动计费每分钟按多少秒算篇十
《移动宽带计费方式探讨》
商业模式BUSINESS MODE
移动宽带计费方式探讨
移动宽带计费方式探讨
文/白驹
价格战并非唯一选择
时长和用户QoS。这三种计费维度并不是独立排它，而是可以并存使用的。运营商
功能等，也可以采用流量包自动升档方式。所谓流量包自动升档，就是当用户的实际用量超出其当前资费包的供给量（Allowance），并且用户因为流量超出部分而需要额外支付的费用加上当前资费包的费用，已经达到并超过下一档资费包的费用时，系统在计费时会自动为该用户升级到下一档资费包，并仅扣除下一档资费包的月租，为用户节省开支。
举个例子，中国联通提供以下三档移动宽带资费包——3GB 150元/月、5GB 200元/月、10GB 300元/月，超出资费包的流量按照0.1元/MB计费。假定用户选择的是3GB的套餐，月租150元。若该用户当月实际用量为4.5GB，那他需要支付的金额将达到150+0.1x1500=300元，就超过了下一档5GB套餐的月租200元。此时，流量包自动升档将发挥其作用，用户资费包自动升档到5GB，用户只需支付200元，相对于原本需要支付的300元节省了100元。
近
年来，移动宽带业务蓬勃发展，但移动宽带接入仍然处于管道类业务的初级阶段。真正
可同时选择流量和时长这两种计费维度，向用户提供更灵活的资费选择；也可以在区分用户QoS的基础上，采用按流量或时长计费的维度。
吸引用户的是移动互联网包罗万象的内容、业务和应用，而移动宽带接入只不过是一个管道，管道本身并不吸引用户，用户仅仅是通过管道接入互联网。
目前，运营商涉足移动互联网的内容、业务和应用还不够深入，因此能做的似乎只有不断下调移动宽带资费，导致价格战此伏彼起。但是，移动宽带价格战并不是运营商的唯一选择。出于差异化的资费竞争需要，运营商应灵活采用移动宽带业务计费策略，通过不同的定价方式，制定出灵活有效的移动宽带资费策略。
定价模式包含计费维度（Charging Dimensionality）和计价方式（Charging Mode），两者之间是层进关系。在考虑定价策略时，我们首先要选择计费维度（如流量、时长），然后再选择具体的计价方式，即在某种计费维度下，确定价格与流量或时长的变化关系。
常见的计费维度有流量、时长、内容、服务等级、次数、距离等。计费维度的基本原则是消费者享用的数量越大，支付越多；消费者享用的产品和服务越好，支付越高；即使是采用Flat-Rate，也要建立在保障赢利的基础上。
移动宽带最常见的计费维度是流量、
按流量计费的原则
按数据流量进行计费，是目前应用最广泛的移动宽带计费方式。
流量计费的最大优点是计费系统易于实现，并且由于数据流量已经被限定，所以运营商无需担心流量滥用。但是，用户对于其所消费的网络流量较难准确把握，流量计费方式不便于用户自我统计。
为了改善用户对网络流量的理解，不少运营商都在其网站上提供用户数据流量估计模型，当用户在选择数据流量包的时候，首先要求用户填写上网行为习惯（比如每天上网时长、下载的内容等）；然后，网站会依据用户输入的数据，估算出该用户一个月消耗的网络流量；最后，依据计算结果向用户推荐一个合适的资费包。
然而，这个模型的估算结果并不精确。用户在上网时，还是不清楚自己究竟消费了多少流量，用户不愿意看到由于流量超出资费包而导致的天价账单。
为了解决这个问题，运营商可以让用户通过SMS等方式实时查询本月使用流量，或者最后50MB流量设置提醒
按时长计费的原则
时长计费就是按照用户上网时长或者按照使用天数来收取上网费用。和流量计费相比，这种方式更容易为用户所理解和接受。
时长计费包括两种形式：一是按有效期计费，通常是以天为单位，或者整数倍的天数，比如资费包设置为2.6美元/天、5.2美元/2天、10美元/周，一旦用户订购该资费包，在有效期内无论用户使用多
29
Huawei Technologies
用户规模，不少运营商推出了无限量包月
（Unlimited Flat-Rate）资费套餐。这在带来可观的用户增长的同时，也带来了较大的网络流量。比如某运营商在推出无限量包月资费包后，在短短一年的时间里就获得了28％的用户增长，并占据3G新增市场份额第一的位置，但与此同时，网络流量
激增20倍。
据统计，使用Flat-Rate计价方式的用户所产生的数据流量是Pay as You Go（按用量计费）用户的5倍，而无限量包月计
使用量（流量或时长）
图
1 移动宽带的各种计价方式
价方式将这种流量刺激效果扩大到50倍，同时带来大量的P2P网络流量。为了保障网络性能，避免网络资源被大量的低价值的P2P流量所占据，运营商需要一种既能
少，都将被扣除资费包标称的资费，逾期则无法使用；二是按照用户实际在网时长计费，套餐包括上网时长、套餐有效期和超出套餐的费率，比如某运营商推出的10小时套餐资费为12.9美元，允许用户在30天有效期内上网10小时，累计超过10小时的部分则按照0.05美元/分钟计价，套餐超过有效期则失效。
2009年7月，北京移动新推出两款按时长计费的移动宽带套餐，分别是60元包60小时、120元包240小时（外加3小时国内漫游），超出部分按0.05元/分钟收费。此前，北京移动主要采用流量计费，分别为20元包150MB、50元包500MB、100元包2GB以及200元包5GB等。
但是，时长计费使得计费系统复杂性加大，存在流量滥用（Abuse）风险。用户在一定时间内，凭借3G网络的高速率，产生大量的数据流量，而这显然不是运营商所期望的。
为解决这个问题，需要设置一个合理的公平使用条款（Fair Usage Policy），探知用户实际用量，并在超出既定流量的时候，收取额外的费用或下调用户的网络接入速率，以避免用户滥用。系统需要探知用户状态（是否上网），统计用户的在线时长，还要避免有些用户在未切断网络连
接的状态下空闲过久。吸引用户，又能有效保护网络资源的计价方式。
按照QoS计费的原则
基于QoS的计费维度，遵循了“用户享用的产品和服务越好，支付越高”的基本原则。比如G国E运营商就提供了两种接入速率的资费包：一是Standard Unlimited（无限量标准包），接入速率为384Kbps，资费为26美元；二是Premium Unlimited（无限量高级包），接入速率为7.2Mbps，资费为52美元。用户在用量超过6GB后，速度会被限制为64Kbps。
QoS计费维度来源于固网宽带，按照不同的接入速率收费。但由于移动网络空口速率的不确定性，这种计费维度目前较难在移动宽带接入领域中广泛应用。
虽然基于QoS的计费维度尚未发展成熟，但这种基于用户体验的差异性定价的理念值得借鉴。随着移动技术的不断发展，不排除这种计费维度在某些特定场景被广泛应用的可能性。
图1列出了移动宽带接入业务的各种计价方式，展示了不同的费用支出和业务用量的变化关系。横轴表示按照某种计费维度的业务用量（比如流量或时长），纵轴表示相应业务用量所支出的费用。
其中，A1和A2主要针对按用量计费用户，两者相比，A2更为复杂但是能更好地刺激用量；B是在A1的基础上添加了资费封顶（Charge Cap），通常这个资费封顶会设置得比较高，主要是用来避免巨额账单（Bill Shock）；C2对于用户来说最具吸引力，也最容易被理解和接收，但将带来大量的网络负荷，因此建议这种计价方式短暂应用于业务推广期，或设置公平使用条款，在用户超出限制流量后降低其接入速率；C3是在C2的基础上设置了流量限制，在用户达到流量限值时会被限制继续使用，这虽然有效防止了滥用，但用户体验并不好；C1是值得推荐的资费包计价方式，给定一个限额，并在超出限额后收取额外资费。
这里所列举的是最基本的计价方式，运营商在实际制定计费策略时，可以组合使用这些计价方式。
责任编辑：许鹏 xupeng@huawei.com
计价方式设计原则
除了利用不同计费维度的差异性，运营商还可以利用计价方式来制定差异化的资费策略。为了发展新用户和扩大
30