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

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

这篇关于运营支撑系统(BSS)在面向物联网IoT业务场景的模型简要分析和设计的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/392420

相关文章

大模型研发全揭秘:客服工单数据标注的完整攻略

在人工智能(AI)领域,数据标注是模型训练过程中至关重要的一步。无论你是新手还是有经验的从业者,掌握数据标注的技术细节和常见问题的解决方案都能为你的AI项目增添不少价值。在电信运营商的客服系统中,工单数据是客户问题和解决方案的重要记录。通过对这些工单数据进行有效标注,不仅能够帮助提升客服自动化系统的智能化水平,还能优化客户服务流程,提高客户满意度。本文将详细介绍如何在电信运营商客服工单的背景下进行

不懂推荐算法也能设计推荐系统

本文以商业化应用推荐为例,告诉我们不懂推荐算法的产品,也能从产品侧出发, 设计出一款不错的推荐系统。 相信很多新手产品,看到算法二字,多是懵圈的。 什么排序算法、最短路径等都是相对传统的算法(注:传统是指科班出身的产品都会接触过)。但对于推荐算法,多数产品对着网上搜到的资源,都会无从下手。特别当某些推荐算法 和 “AI”扯上关系后,更是加大了理解的难度。 但,不了解推荐算法,就无法做推荐系

基于人工智能的图像分类系统

目录 引言项目背景环境准备 硬件要求软件安装与配置系统设计 系统架构关键技术代码示例 数据预处理模型训练模型预测应用场景结论 1. 引言 图像分类是计算机视觉中的一个重要任务,目标是自动识别图像中的对象类别。通过卷积神经网络(CNN)等深度学习技术,我们可以构建高效的图像分类系统,广泛应用于自动驾驶、医疗影像诊断、监控分析等领域。本文将介绍如何构建一个基于人工智能的图像分类系统,包括环境

水位雨量在线监测系统概述及应用介绍

在当今社会,随着科技的飞速发展,各种智能监测系统已成为保障公共安全、促进资源管理和环境保护的重要工具。其中,水位雨量在线监测系统作为自然灾害预警、水资源管理及水利工程运行的关键技术,其重要性不言而喻。 一、水位雨量在线监测系统的基本原理 水位雨量在线监测系统主要由数据采集单元、数据传输网络、数据处理中心及用户终端四大部分构成,形成了一个完整的闭环系统。 数据采集单元:这是系统的“眼睛”,

Hadoop企业开发案例调优场景

需求 (1)需求:从1G数据中,统计每个单词出现次数。服务器3台,每台配置4G内存,4核CPU,4线程。 (2)需求分析: 1G / 128m = 8个MapTask;1个ReduceTask;1个mrAppMaster 平均每个节点运行10个 / 3台 ≈ 3个任务(4    3    3) HDFS参数调优 (1)修改:hadoop-env.sh export HDFS_NAMENOD

性能分析之MySQL索引实战案例

文章目录 一、前言二、准备三、MySQL索引优化四、MySQL 索引知识回顾五、总结 一、前言 在上一讲性能工具之 JProfiler 简单登录案例分析实战中已经发现SQL没有建立索引问题,本文将一起从代码层去分析为什么没有建立索引? 开源ERP项目地址:https://gitee.com/jishenghua/JSH_ERP 二、准备 打开IDEA找到登录请求资源路径位置

Andrej Karpathy最新采访:认知核心模型10亿参数就够了,AI会打破教育不公的僵局

夕小瑶科技说 原创  作者 | 海野 AI圈子的红人,AI大神Andrej Karpathy,曾是OpenAI联合创始人之一,特斯拉AI总监。上一次的动态是官宣创办一家名为 Eureka Labs 的人工智能+教育公司 ,宣布将长期致力于AI原生教育。 近日,Andrej Karpathy接受了No Priors(投资博客)的采访,与硅谷知名投资人 Sara Guo 和 Elad G

嵌入式QT开发:构建高效智能的嵌入式系统

摘要: 本文深入探讨了嵌入式 QT 相关的各个方面。从 QT 框架的基础架构和核心概念出发,详细阐述了其在嵌入式环境中的优势与特点。文中分析了嵌入式 QT 的开发环境搭建过程,包括交叉编译工具链的配置等关键步骤。进一步探讨了嵌入式 QT 的界面设计与开发,涵盖了从基本控件的使用到复杂界面布局的构建。同时也深入研究了信号与槽机制在嵌入式系统中的应用,以及嵌入式 QT 与硬件设备的交互,包括输入输出设

JAVA智听未来一站式有声阅读平台听书系统小程序源码

智听未来,一站式有声阅读平台听书系统 🌟 开篇:遇见未来,从“智听”开始 在这个快节奏的时代,你是否渴望在忙碌的间隙,找到一片属于自己的宁静角落?是否梦想着能随时随地,沉浸在知识的海洋,或是故事的奇幻世界里?今天,就让我带你一起探索“智听未来”——这一站式有声阅读平台听书系统,它正悄悄改变着我们的阅读方式,让未来触手可及! 📚 第一站:海量资源,应有尽有 走进“智听

Retrieval-based-Voice-Conversion-WebUI模型构建指南

一、模型介绍 Retrieval-based-Voice-Conversion-WebUI(简称 RVC)模型是一个基于 VITS(Variational Inference with adversarial learning for end-to-end Text-to-Speech)的简单易用的语音转换框架。 具有以下特点 简单易用:RVC 模型通过简单易用的网页界面,使得用户无需深入了