图2 配置数据流量：初始状态

如图3 所示，SurePay 系统为用户1 的任务分配了200MB的数据流量，这是从该账户组总流量中分配的。在后续的用户任务的信息更新中，网络会报告该用户使用了多少的流量，如果需要，可以申请附加的流量。

图3 为用户分配数据流量配额：为用户1 预留200MB

然而， 在尚未消耗的数据量返回计费系统前，计费系统并不能确切地得知有多少分配的数据量已经使用。换句话说，在用户使用任何业务过程中，总有一段时间是不能确定业务完成后会有多少流量返回到月度共享流量计划中。这样，所谓的实时信息也无法做到精准的数据均衡。

当许多数据业务同时并发时，余量数据均衡的不确定性就会增加，出现数据饥渴症，影响数据使用报告的及时性及准确性。

分配协议的制定

上述普遍存在的问题，原则上可以通过分配更小的数据切片包来解决。并发业务越多，数据包就越小。然而，这种办法也并不完全实用，因为分配的数据容量包越小，并发业务使用时产生的信令和负荷就大大增多，会对数据网内的网关和计费系统产生影响。

为维持避免数据饥渴症和减少信令负荷之间的平衡，对终端数据配额的分配需要复杂的机制保障。一般情况下，在多业务并发的数据任务中，可以采用多样化的手段。例如，终端的数据额度可以是月度总额度的适当比例，随月度中日期的变化，可分派的包就越来越小；并且限制在某个最小、最大值之间。数据额度也可根据某些静态属性切分，如终端设备的类型、接入方式或者业务类别等等。它也可以根据动态属性分配，如位置信息、使用情况等。也可采用以上多种方式的混合设定。

然而，以上这些机制并不能完全解决问题。为保障精准地使用数据包，解决数据饥渴症，需要更为复杂的机制。而且，要保证在需要的时候，分切的数据包可以进行实时的变化。

理想情况下，分配给某个任务的数据包额度应该符合执行该任务的使用模型，在满足需求的同时减少共享帐号中所有任务的信令负担。如果在为某任务分配数据包时不考虑如何使用，将可能使新的任务产生数据饥渴症。为解决这种情况下出现的问题，先前分配给其它任务中未使用的数据将被回收。这种方式，对本来要拒绝的业务将提供新的取舍选择。