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

标签: 系统 bss 物联网 | 发表时间:2017-09-17 21:33 | 作者:lottons88
出处:http://www.iteye.com

前言

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、保证业务语义能够被清晰的表达出来,在清晰表达的基础上确保足够的简单。否则,如果模型在表达想要面对的业务语义具有一定的二义性或者复杂性,那么对实现将会是极大的挑战。



已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [系统 bss 物联网] 推荐:

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

- - 企业架构 - ITeye博客
BSS运营支撑系统(主要指电信运营商),通常都是为了支撑个人客户的业务运营. 虽然在业务运营上也面向集团客户,但是总体上来说,业务的特性总结归纳为2C的业务场景. 而当前运营商在面向物联网的业务运营下,主要是以2B的业务场景. 运营商实际并不会直接面向最终的客户,而是通过其他业务的运营企业的合作或者买卖关系提供,即是一种B2B2C的场景.

Google物联网操作系统

- -
本次,谷歌正式将其物联网Brillo系统更名为Android Things,并同时更新了通讯协议weave.. 与Android TV Android Auto和Android Wear统一名称,稳定发展. Android Things为开发者快速打造物联网设备底层系统,开发者可以使用Android API和Google服务,结合Android Studio Google Cloud Platform及Google Play来操作,已开放预览版.

谷歌以物联网操作系统Android Things进军物联网

- - IT瘾-tuicool
谷歌给物联网设备的开发带来了Android及其生态系统. 开发人员将像之前他们为移动设备编写应用程序那样,为这些设备编写应用程序. 谷歌已经将一些Brillo的主要技术结合到了他们的移动操作系统中,也就是名为 Android Things的以物联网设备为目标的新解决方案. 尤其是,用户驱动API允许开发人员在原厂设置提供的现有功能之外,扩展对物联网设备可以做的事.

物联网系统设计工具箱——Dashboard框架Dashing

- - CSDN博客架构设计推荐文章
Dashboard的原义是仪表盘,作为一个查看的工具来说这个名字还算不错. Dashing是一个不错的Dashboard框架,原文的意思是The exceptionally handsome dashboard framework.. 一个类似于fancybox的弹出框,从当前来看没有fancybox强大.

面向物联网的几大开源操作系统

- - 开源中国社区最新新闻
在过去的十年间,大多数新型开源操作系统已从移动市场转向物联网市场. 本文介绍了面向物联网的许多新型开源操作系统. 我们之前的文章介绍了开源物联网框架,以及面向物联网和消费者智能家居设备的Linux和开源开发硬件. 除了介绍面向物联网的新型嵌入式Linux发行版外,我还介绍了OpenWrt等几款比较老的轻量级发行版,它们在这个领域迎来了新生.

多如牛毛的物联网操作系统

- -
  今天 PC 和手机时代的操作系统霸主未必能在物联网时代延续霸业. 操作系统产业的规律是,当垄断已经形成,后来者就很难颠覆,只有等待下一次产业浪潮. 如今,一个全新的、充满想象空间的操作系统市场机会正在开启.   如此关键的产业环节必然是兵家必争之地. ARM、谷歌、微软、华为、阿里、海尔等国内外著名的 IT 企业纷纷推出物联网操作系统,整个产业呈现出群雄逐鹿的壮观景象.

深入解析物联网操作系统(架构/功能/实例分析)

- - IT瘾-geek
1.       物联网的主要特点.                        i.             连接. 所谓连接,指的是各种各样的终端设备,都能够通过某种网络技术,连接到一个统一的网络上. 下一代的基础通信网络,包括未来的5G,通信网络架构重构等,为物联网提供泛连接网络是核心目标.

以.NET MF为依托,打造物联网时代轻量级嵌入式组态系统

- 王雪松 - 博客园-首页原创精华区
作者: 叶帆 发表于 2010-09-20 22:47 原文链接 阅读: 1486 评论: 12. 在工控领域,组态软件司空见惯,国外的iFix、InTouch、WinCC,国内的组态王、力控、MSCG等等. 组态软件的出现彻底解决了软件重复开发的问题,实现模块级复用,好处不仅仅是提高了开发效率,降低了开发周期,更大的优势的是成熟模块的复用,大大提高了系统稳定性和可靠性.

公开了:统治物联网的不为人熟知的开源操作系统

- - 博客园_新闻
英文原文: Out in the Open: The Little-Known Open Source OS That Rules the Internet of Things. 差不多所有东西都可以连接到计算机网络. 獾大部分时间在地下,给生物学家和动物学家追踪它们的下落和活动增加了难度. 比如,GPS 在地下或密闭区域运作不正常.

为什么选择Zephyr操作系统开发物联网产品?HereO、CommSolid和Grush有话说

- - 奇笛网
万物联网时代,物联网设备以百花齐放的态势涌向市场,让众多用户体验到互联所带来的智能体验. 物联网设备也以开发成本低、开发周期短吸引了一波创业者的目光,从而造就了当前物联网市场百家争鸣的热闹格局. 除了硬件设计,摆在创业者面前最直接的问题就是:如何为自己的物联网设备选择一款合适的操作系统. 操作系统对于物联网设备而言,与互联网中的Windows同等重要.