运营支撑系统（BSS）在面向物联网IoT业务场景的模型简要分析和设计

前言

BSS运营支撑系统（主要指电信运营商），通常都是为了支撑个人客户的业务运营。虽然在业务运营上也面向集团客户，但是总体上来说，业务的特性总结归纳为2C的业务场景。

而当前运营商在面向物联网的业务运营下，主要是以2B的业务场景。运营商实际并不会直接面向最终的客户，而是通过其他业务的运营企业的合作或者买卖关系提供，即是一种B2B2C的场景。

在面向物联网的业务场景下，当前2C的BSS系统模型需要进行分析和改进。物联网的业务场景下，对数据量的存储是一个挑战。通常一个物联网业务的运营企业，通常会一次批量购买大量的SIM，使用运营商提供的网络服务，如数据流量、短信、语音。下面以此以3个典型的IoT物联网的业务场景作为依据，对模型进行简要的分析和设计。

场景一：

某企业一次性从运营商购买了一批（10万张）卡，这批卡具有相同的使用量和资费，即：每个月10元，50M数据流量，10分钟的语音通话时长，30条SMS短信。

1） 模型1

面向传统个人订购的三户模型
 
数据量：10万条Subscriber记录，10万条Offering实例记录，30万条Product实例记录，共计50万条数据记录。
在这种模型下，可以表达出每张卡的订购信息。尤其是在当前场景下，每张卡都是拥有独立的用户信息，独立的Offering实例信息。如果需要在每张卡的使用量超出限额的情况下，针对超出限额的卡进行单独的信控如停开机操作。这种模型下，只需要操作对应的Subscriber即可。虽然，这种模式带来了较多的数据冗余的结果。这10万张卡形成的Offering实例、Product实例的数据都是完全相同的。在IoT的场景下，会有大量的这种情况存在，那么就会有大量的冗余数据进行存储。

2）模型2

在模型1的基础上进行调整，考虑在Subscriber下增加一张Device表，专门用来基于“卡”的信息。 
 
数据量：10万条Devices记录（Custom、Subscribe、Offering实例、Product实例数据可以忽略）。这样就表达了这10万张卡设备在同一个Subscriber下，使用相同的Offering实例和Product实例数据。也就是实用相同的资费和资源用量。
这种模型，在业务逻辑上表达是Device使用了Subscribe下记录的Offering和Product实例。如果某一个Device的使用量超出了限额用量，那么针对这个Device的信控操作需要记录在Device中对应对应的记录上。同时，针对某些Device的服务控制。如当前所有的Device都开通了流量、语音、SMS，如果针对其中10张卡进行语音的关停。那么就会有两种表达方式：
方式1：将这10张卡做改产品的操作，重新生成Subscriber、Offering实例和Product实例数据（这10张卡信息记录到这个Subscriber下）。
方式2：Device中记录有对网络服务的状态定义，如流量【开/关】、语音【开/关】、SMS【开/关】。对其中10张卡的操作可以记录到对应的网络服务的状态上，也就是说这10张卡的语音网络服务的状态由【开】变为【关】。
方式1存在的问题，如果频繁的对设备（Device）进行网络服务的变更操作，会导致不断地形成新的Subscriber，从而数据逐渐的碎片化。最后的结果就是和模型1是相同的效果。
方式2存在的问题，Subscribe下记录的Product实例数据已经没有办法准确的表达出设备（Device）的网络服务状态，Device真实的状态是记录在Device中的每条Device记录上。

3）模型3

面向集团订购的三户模型 
 
基于集团客户订购的三户模型，在表达此种场景其实有两种表达方式。
一种方式就是在Group下成员的Subscribe下单独记录Offering实例和Product实例数据。这种表达方式就和模型1是相同的，唯一不同的是用Group将所有的Subscribe进行了聚合。
另一种方式，就是在Group上记录Offering实例和Product实例数据。而在成员的Subscriber下不在记录Offering和Product实例数据。这种表达方式其实和模式2有些类似，将Subscribe表达为Device。将Group上的Offering和Product实例数据在成员的Subscribe上生效。
方式一的表达方式从业务语义上是较清晰的，客户为每一个Device都订购了各自独立的Offering。虽然，这些Offering在订购的时候是完全相同的。但是业务语义表达的应该是每个设备订购，每个设备独立使用（独立信控？）
方式二的表达放方式在业务语义上，代表着Group上的Offering实例是作用于所有成员上。即，成员没有Offering实例就取Group上的Offering实例。这种方式下，如果频繁的对设备进行网络服务的变更操作，会导致不断地在变更设备的Subscribe下生成Offering实例和Product实例数据。

 

场景二：

某企业一次性从运营商购买了一批（10万张）卡，这批卡每个月共享50G的流量，1000分钟的语音和1万条的SMS。

模型1：

面向传统个人订购的三户模型 
 
数据量：10万条Subscribe数据、10万条Offering实例数据、30万条Product实例数据，共50万条数据记录。
在每个Subscriber下都记录同一个Offering实例，其所规定的使用量实在这些拥有相同Offering实例的Subscribe下共同使用。
在和计费系统集成时，所定义的Offering必须要能够表达出这样的含义，才能向计费系统表达出这样的业务语义。也就是说，offering的定义必须要能够表达出这是一个“共享”的offering。
问题：针对其中某一些卡进行单独的网络服务控制，如关闭语音。在这种模型下是通过改产品来表达？如果通过改产品，是否需要根据需要列举出产品的组合，针对这些产品的组合定义对应的Offering来表达？这样，就意味着相需要根据列举的产品组合进行Offering的定义。虽然可能有一些Offering只包含了部分产品，但是仍然要能够表达出这是一个“共享”的offering。

模型2：

在模型1的基础上进行调整，考虑在Subscriber下增加一张Device表，专门用来基于“卡”的信息。 
 
数据量：10万条Device数据、1条Subscribe记录、1条Offering实例数据、3条Product实例数据。
表达共享的Offering作为Subscribe下的Offering实例数据，就表示了所有的设备（Device）共享同一个Offering定义的用量。对这些卡的信控，应该是集体处理。当用量超出限额时，批量将这批卡进行停机。复机也是对这批卡进行。
对这批卡中部分卡（单个卡）的网络服务状态的变更，参考场景一中模型2对应的描述。

模型3：

面向集团订购的三户模型 
 
数据量：10万条Subscribe数据、1条Group数据、
在该场景下，Group上的的Offering实例数据所表达的业务语义是：成员Subscriber共享用量。和场景一下，Group上的Offering实例所表达出来的业务语义已经有了区别。在这两种场景下，虽然都是在Group上的Offering实例数据，但是表达业务语义，一个是独立作用于所有的成员，一个是共享作用于所有成员。这样，在定义Offering的时候就必须能够区分出来，这个Offering是在成员间共享，还是独立作用于成员。

 

场景三：

某企业一次性从运营商购买了一批（10万张）卡，其中有1万张卡为VIP客户使用，除了可以使用这批卡共享的50G流量，1000分钟语音，1万条SMS外。本身还提供了500M定向流量和100分钟额外的语音的叠加用量。

模型1：

面向传统个人订购的三户模型 
 
数据量：10万条Subscriber数据，11万条Offering实例数据，32万条Product实例数据。
这种模型下，对于1万张具有独立的资源用量的卡，分别需要两条Offering实例：1条表示共享的用量定义offering；一条表示独占的用量定义offering。

模型2：

在模型1的基础上进行调整，考虑在Subscriber下增加一张Device表，专门用来基于“卡”的信息。 

 这种场景下，这个模型的表达就比较的别扭。具有独占资源使用量的1万张vip卡，独立为一个新的Subscribe记录，同时记录在Subscribe下的Offering实例数据表达的是独享Offering。但是，这1万张卡又要使用共享的Offering用量。也就是说，从业务逻辑上来说，这个Subscriber要使用其Custoemr下另一个Subscriber下的Offering实例的数据。因为，那里记录了共享用量的Offering实例和产品实例信息。如果，这个Customer下拥有不同的Subscriber，那么要么遍历所有的Subscriber，找出其中记录有共享用量的Offering实例数据。要么就是在Subscriber上具有标识，表示这个Subscribe是共享的Offering。要么就是在Device上进行冗余存储，共享的Subscriber下记录所有的Device，独占的Subscribe下记录有只用于独占Offering的Device。问题就在于数据的一致性上，需要同时保证至少两张表以上的冗余数据是一致的。

模型3：

数据量：10万条Subscribe数据，1万+1条Offering实例数据，2万+3条Product实例数据。
在这种场景下，有9万条Subscriber下是没有Offering实例数据和Product实例数据。只有具有独占Offering的Subscribe下才有对应的Offering实例数据和Product实例数据。
在成员下的Offering实例表达了改成员订购了作用于自己的Offering。
进一步思考，此模型从业务语义的表达上会更清晰的反馈出业务的语义。但是，也存在Offering具有数据冗余的情况。即存在1万条相同的Offering实例数据和相应的Product实例数据。
一种改进： 

 将原来独占Offering记录在Subscriber下的数据，记录在Group下。通过Subscriber建立和改Offering实例数据的关联关系，表示原来这些Subscribe独占Offering的业务语义。
存在问题：从业务语义上来说，在表达Offering实例的作用域没有原来在Subscribe下记录Offering实例来的清晰。这是通过一种隐含的关联关系来表达，所有的Offering实例都是记录在Group。但是并不是所有的Offering实例都作用于每个成员，而是作用于部分成员。作用的范围是通过成员Subscriber上关联的Offering实例来表达。

实际上，就模型来说模型的设计可以是非常的灵活。但是有一点是需要能够保证的：1、保证业务语义能够被清晰的表达出来，在清晰表达的基础上确保足够的简单。否则，如果模型在表达想要面对的业务语义具有一定的二义性或者复杂性，那么对实现将会是极大的挑战。