通信网络、方法、网络设备和通信设备

技术领域

本公开总体上涉及用于提供分布式分类账的通信网络、用于将移动即服务提供给网络设备的方法以及通信设备。

背景技术

通常，已知在诸如实体(即记录数字交易的电子设备，服务器等)的多个节点上分布分类账。分布式分类账可以基于已知的区块链技术，例如，已知的加密货币比特币基于该技术，但是也可以基于著名的以太坊项目等。通常，分布式分类账也可以在区块链技术以外的其他技术上实现，并且不基于区块链的分布式分类账项目的示例是Bigchain DB和IOTA等。例如，IOTA是使用链表的加密货币。

此外，已知移动即服务(MaaS)，其中用户或乘客使用移动即服务而不拥有例如汽车等。移动即服务可以将来自关联运营商或提供商的公共(例如火车，公交车等)和私人(例如汽车共享、自行车共享等)交通服务结合起来。

已知的MaaS解决方案通常涉及中央和统一的网关，通过该网关可以规划和预订行程或旅程，用户可以在其中使用单个账户付款。

尽管存在用于提供分布式分类账和移动即服务的技术，但是通常期望提供用于提供分布式分类账的通信网络、提供移动即服务的方法、网络设备和通信设备。

发明内容

根据第一方面，本公开提供一种用于提供分布式分类账的通信网络，包括被配置为向其他节点提供分布式分类账功能的至少一个节点。

根据第二方面，本公开提供一种提供移动即服务的方法，包括在多个节点上维护分布式分类账，其中，分布式分类账包括使用移动即服务的用户的旅程数据。

根据第三方面，本公开提供一种网络设备，其包括被配置为在多个节点上维护分布式分类账的电路，其中该分布式分类账包括使用移动即服务的用户的旅程数据。

根据第四方面，本公开提供一种通信设备，其包括被配置为访问多个节点上的分布式分类账的电路，其中该分布式分类账包括使用移动即服务的用户的旅程数据。

在从属权利要求、以下描述和附图中阐述了其他方面。

附图说明

参照附图通过示例的方式说明实施例，其中：

图1示意性地示出了区块链；

图2示意性地示出了区块链中的哈希；

图3是示出共识协议的实施例的流程图；

图4示出了MaaS系统中的数据流；

图5示出了包括旅程日志数据的区块链的实施例；

图6示出了用于提供区块链的通信网络的实施例；

图7示出了用于基于边缘节点提供区块链的通信网络的实施例；

图8示出了虚拟化基础设施的实施例；

图9示出了移动边缘计算的实施例；

图10示出了基于边缘计算提供区块链的通信网络的实施例；

图11示出了云计算中的区块链处理的实施例；

图12示出了收入份额的实施例；

图13示出了利用分布式分类账进行净销售额计算的方法的实施例；

图14示出了用于利用分布式分类账进行收入份额计算的方法的实施例；

图15示出了在一些实施例中使用的区块链的数据结构的示例；

图16是用于计算收入份额的表；

图17示出了收入提供的实施例；

图18示出了通过平衡相同量来提供收入的实施例；

图19示出了基于代理的收入提供的实施例；

图20示出了基于代理的收入提供的实施例，其中代理具有最高盈余；

图21示出了在一些实施例中基于其实现网络设备或通信设备的通用计算机的实施例；以及

图22示出了eNodeB和用户设备彼此通信的实施例。

具体实施方式

在给出参考图1的实施例的详细描述之前，进行一般的解释。

如开头所述，通常已知分布式分类账和移动即服务(MaaS)。

在一些实施例或方面中，本公开总体上涉及用于移动即服务(MaaS)应用的区块链/分布式分类账的应用，特别是不止一个服务提供商之间的MaaS(多模式传输)。

在一些实施例或方面中，本公开总体上还涉及分布式分类账或区块链的应用，作为分布式分类账的一个示例，而不将本公开内容限于区块链。根据本公开的一些方面，分布式分类账或区块链被认为适合于移动即服务(MaaS)应用，因为分布式分类账需要用于多个玩家之间的旅程历史(或旅程数据)的分布式数据库，即多个移动即服务提供商。

本公开的一些方面涉及MaaS服务提供商的收入份额，其可以禁止多玩家之间的数据库不一致。

在一些实施例中，MaaS区块链可能需要处理大量乘客，存储各种旅程记录，大块区块，高峰时段的处理高峰等。

已经认识到，传统的私有区块链(例如，用于加密货币)可能会有一些限制。例如，在私有区块链的情况下，交易数量有限(例如，每秒七笔交易)，有限的块大小(最大2M字节)，一次交易的间隔长(每10分钟)可能会使这样的常规私有区块链不方便，甚至对于MaaS实施例都没有用。

因此，本公开的某些方面涉及以下问题：哪种类型的区块链用于MaaS，什么样的数据应该存储在块中，需要什么样的区块链功能，例如添加块，共识协议，读取数据等，这可能与加密货币等其他区块链应用至少部分不同。

在下文中，给出了一些术语定义，其可以在一些实施例中应用(不将本公开限制于以下给出的定义。定义仅是示例，其被提供用于增强对本公开的理解，并且仅给出了这些信息，因为MaaS和分布式分类账的技术领域是高度动态的，并且定义将来可能会更改)。

术语“分布式分类账”可以从Wikipedia中得知，其定义：“分布式分类账(也称为共享分类账，或分布式分类账技术，DLT)是地理分布在多个站点、国家或机构上的复制、共享和同步数字数据的共识。没有中央管理员或集中式数据存储。”

分布式分类账的技术及其特殊示例(即区块链)的技术也将在下面进一步讨论。更一般地，术语分布式分类账被用作与网络的多个节点共享数字记录的数据的一种数据库。它可能包含对等网络。数字记录的数据可以包括一种信息，以根据先前在同一数据库中记录的数据证明其一致性。

分布式分类账可以是公共的，且任何人都可以访问，但是，原则上，它们也可以是非公共的，且只有获得许可的用户才可以访问它们，其中具有许可的一组实体、节点、人员、操作员、提供商等也可以称为“联盟”，这也将在下面进一步解释。也可以区分每个分层用户对分类账上数据的访问权限。

分布式分类账可以使用例如从用于比特币的区块链技术中已知的机制。这些机制包括发现方法，共识机制，保持数据一致性的机制等等。共识机制可确保具有分布式分类账副本的所有节点或多于一定数量的节点(通常是电子设备)具有分布式分类账的副本，可以就分布式分类账的内容达成共识。有许多共识机制，包括所谓的工作量证明机制，这是一种加密难题，且其可确保例如不能(不容易)更改区块链的旧块。例如，工作量证明用于比特币区块链的挖掘过程。

在分布式分类账或区块链中，对参与节点上的区块链上的数据更新达成共识的确认过程(称为挖掘过程)可以通过将先前记录的数据包括在确认数据中来实现记录在区块链上的交易序列的不可逆性。这种挖掘过程为新的事务块实现了分布式时间戳服务器。在比特币中(因此，在某些实施例中)，挖掘过程基于SHA-256哈希函数。参与挖掘过程的区块链节点搜索具有预定义属性的哈希输出，而哈希函数的输入取决于区块链的当前区块和要添加到区块链的新交易区块。

基于哈希函数的工作量证明计算本身可能没有用，只是需要它们来实现分布式分类账的不可逆性。

而且，通常，已知使用区块链来存储各种数据。例如，图像、视频、测量和文本文件可以交易形式记录在区块链上。

Wikipedia也提供“移动即服务(MaaS)”一词，该术语定义：“移动即服务(MaaS)描述了从个人拥有的交通方式向服务即消费的移动解决方案的转变。通过创建和管理行程的统一网关，将公共和私人交通提供商的运输服务组合在一起，用户可以通过一个账户付费。用户可以为有限距离的每次旅行或按月付费。MaaS背后的关键概念是基于旅行者的旅行需求提供旅行者出行解决方案。”

在一些实施例中，如上所述，“公共区块链/分布式分类账”意味着任何人都可以共享分布式数据库(分类账)并加入以执行共识协议。

与此相反，“许可的区块链/分布式分类账”意味着只有允许的成员才能共享分布式数据库(分类账)并加入共识协议。如上所述，允许访问区块链的许可成员称为“联盟”。在一些实施例中，许可/联盟类型的区块链适合于MaaS应用，因为它们不是公共的，因此没有人可以访问它。

术语“(移动)边缘计算”也可以在Wikipedia上找到，该词定义：“多路访问边缘计算(MEC)，原为移动边缘计算，是一种网络架构概念，在蜂窝网络[l][2]的边缘，尤其是在任何网络的边缘，都可以启用云计算功能和IT服务环境。MEC的基本思想是，通过运行应用并执行更接近蜂窝客户的相关处理任务，可以减少网络拥塞，并提高应用的性能。”

在网络虚拟化环境中，术语“北向API”应理解为电信运营商可以使用基于软件的接口(API)配置网络功能，并且网络运营商可以配置虚拟基础设施(例如虚拟机)并请求网络功能/应用功能。

术语“实例”被理解为在云上运行的软件过程。它可能会移动分布式云中的某些位置。

“公有云”可以定义为(https://azure.microsoft.com/en-gb/overview/what-are-pri-vate-public-hybrid-clouds/)：“公有云是部署云计算的最常见的方式。云资源(如服务器和存储)由第三方云服务提供商拥有和运营，并通过互联网交付。”

在某些实施例中，在给定的理解中将使用以下术语：

术语“多式联运通行证”可以是对具有特定条件(例如有效期或可用运输，不可接受的服务等)的多种出行服务有效的通行证。例如，一日票证，一周票证，每月MaaS服务订购，季节性票证等。

术语“移动服务提供商”可以是任何类型的服务提供商MaaS的统称。在一些实施例中，它通常是运输组织，例如铁路公司、公交车/长途汽车、电车和出租车、汽车共享、拼车、自行车共享等。一些移动服务提供商可能没有提供实际的交通工具，而是可能仅提供与旅行社或在线预订站点等相比的预订/安排。

术语“通行证”可以是公交通行证或旅行卡(英国)(另请参见https://en.wikipe-dia.org/wiki/Transit_pass)。在本公开中，多式联运通票也应属于术语“通行证”，这意味着该通行证可能在不止一个运输运营商(或移动服务提供)中有效，并因此，它不仅可以覆盖公众运输，还涵盖其他类型的出行方式，例如拼车、自行车共享等。通行证可能包括可接受的交通、有效期以及任何其他票证发行/运输乘车条件的信息。MaaS可能会提供每月的服务订购，并在某些实施例中提供一些服务级别选项。乘客或用户可以向通行证发行者(通常可以是发行通行证的移动服务提供商)支付服务订购费或购买特定时期的通行证。该通行证可以由运输运营商或旅行社、MaaS服务提供商等签发(它们都可以归入上述“移动服务提供商”一词)。因此，如上所述，一些通行证发行者可以出售通行证，但可能不提供实际的运输服务或运输手段。

术语“票证”可以是特定部分的单程票证，例如带(或不带)座位的单程火车票证。在某些实施例中，票证可以在多式联运通票及其条款和条件下发行，并且可以包括选择的交通、座位号、价格等信息。在某些实施例中，即使不需要预订座位或允许无限制旅行，也可以发行票证以在多个移动服务提供商之间收入份额。此外，乘客(用户)可能不会直接向票证发行者付款，而通行证发行者可能会代替乘客向票证发行者付款，并且票证可以由运输运营商或服务提供商(即移动服务提供商)发行。

术语“旅程日志”可以涵盖旅程日志，其是基于票证的单程旅程记录。它可以包括关于堤岸的位置，其时间/日期，下车的位置，其时间/日期，票证是已使用还是未使用等的信息，这也将在下面进一步讨论。

在下文中，给出了描述的总体概述，其中将讨论本公开的四个不同方面的实施例，其可以被实施或实现为单独的方面，或者可以以任何可能的组合彼此组合。

作为第一个方面，MaaS功能和区块链的一般构建块被解释为分布式分类账的示例。移动服务提供商可以具有示例性的MaaS关键功能，例如预订、付款等。示例性地与移动服务提供商共享区块链。

作为第二方面，说明了区块链(或分布式分类账)的区块的内容和区块的链。运输服务提供商(这是移动服务提供商)发行票证并记录旅程。区块链中的一个区块包括多个移动服务提供商之间的乘客旅程，并将其冻结(不可变)。移动服务提供商可以例如在稍后的时间点访问分布式分类账中的记录。

作为第三方面，说明了架构或(通信)网络/拓扑。在某些实施例中，网络中不需要集中式服务器或集中式组织器。在移动服务提供商之间可以使用被配置为对等网状网络的通信网络。此外，代替或除了移动服务提供商之外，电信网络运营商还可以为其提供区块链服务或功能以及通信网络。

作为第四方面，讨论了具有分布式分类账的收入份额计算的示例。计算可能非常简单，且移动服务提供商可能不必照顾其他提供商的计算。可以在没有集中授权的情况下(例如，不通过银行)在移动服务提供商之间分配/转移所计算的(正确的)收入金额。

在下文中，将参考图1来解释区块链及其一般数据结构。在区块链的该实施例中，特征是网络/拓扑，共识算法，哈希函数，参与者认证，可伸缩性/块结构和性能。

图1示出了区块链1的一般结构。区块链1包括由多个数据块2a，2b和2c组成的链，其中块2b是当前块(块#N)，块2a是先前的块(块#N-1)，块2c是未来的块或后继块(块#N+1)。每个块包括前一个块的哈希函数结果、主数据结构、哈希函数的输入值和当前块的哈希函数结果，其中，当前块(2b)的哈希函数结果始终用作输入下一块(2c)。

此外，每个块都包含一个“已使用一次的编号”，这是用于安全区块链处理的一次性随机数，可以防止回放攻击。例如，如果攻击者复制了先前发送的数据并再次将复制的数据重新用于欺骗，则接收机能够检测到欺骗通信，因为下一个数据必须使用不同的“使用一次的编号”。该随机数有时在加密货币中称为“随机数”。

另外，可以将时间戳插入每个块2a，2b和2c中。区块链1是分布式分类账的示例，在某些实施例中，其可用于例如提供MaaS。

图2举例说明了哈希函数的输入和输出，其例如用于图1的区块链1。

通常，哈希函数是可以用于使用特定算法将输入数据映射到输出数据的任何函数。输入数据的大小可能很大且各不相同，相反，数据的输出可能会很紧凑并且具有固定的大小。在某些区块链实施例中，用于哈希的已知(和著名的)算法是由美国国家安全局(例如SHA-2，SHA-256)设计的安全哈希算法(SHA)。

哈希函数的输入是先前的哈希输出，一次使用的数字以及当前块(例如，图1中的块2b)中的数据主体。哈希函数的输出是对输入值的唯一值响应。如果有人试图篡改数据主体，则哈希函数的输出将不一致。

本公开中的分布式分类账(区块链)的实施例可以实现共识协议或算法。例如，在一些实施例中，拜占庭式容错(BFT)用于共识协议，该协议对于数据库的欺骗和硬件的故障具有弹性。

在一些实施例中实现的众所周知的共识算法是所谓的实用拜占庭式容错(PBFT)。

在一些实施例中，使用许可区块链，并且相对较少数量的许可区块链节点负责共识(区块验证)。

图3示例性地示出了PBFT的过程10。

在11处，领导者节点(也称为非验证对等方)在其他节点上请求验证区块链。在12处，每个请求的节点(验证对等方)使用哈希函数检查区块链的有效性，并在13处向其他节点指示其结果。在14处，节点从其他多个对等节点接收有效性结果，并检查其区块链的共识性(如果节点收到的有效性结果比预定义标准还多)。如果达成共识，则在15处，节点写入/完成区块链。领导者对等检查其他节点中有效性检查的总体进度，并在16处完成区块链过程。

对于弹性，在一些实施例中，节点的总数大于3f+1，其中f是允许的故障节点的数量。例如，f＝1，总共有4个节点；如果f＝3，则总共有10个节点，依此类推。

在一些实施例中，如本文所讨论的，PBFT具有用于移动服务区块链的许可区块链，至少部分地提供以下特征：

关于安全性，在某些实施例中，PBFT提供了51％攻击的少许风险，这对于加密货币是很常见的，因为负责共识的同级必须获得允许的信任。关于隐私，终端用户无法访问整个区块链，因为仅移动服务提供商在(对等)节点上处理它(由于基于权限的区块链，终端用户可能没有访问区块链的许可)。关于性能，在一些实施例中，由于少数具有高性能的对等体，用于共识的处理时间非常短。关于灵活性，在一些实施例中，与公共区块链相比，区块链的块大小和格式可以是灵活的。

在下文中，参考图4说明MaaS系统20的数据流，其示出了整个数据流。在MaaS系统20中，示例性地假设终端用户具有自己的终端21，例如智能电话(或任何其他类型的电子(移动)设备)。一些用户(例如来自国外的访客)可能没有智能手机等，并且在这种情况下，例如，可以提供一种替代解决方案，该解决方案基于图4中的代理功能(代理22)，该代理功能向用户提供门。

图4示出了MaaS系统20的数据流程图，其中提供了三个主要部分，在左侧提供了终端用户部分，在中间提供了移动服务运营商/提供商部分，并且在右侧提供了其他实体部分，其中终端用户部分和其他实体部分与中间的移动服务提供部分通信。

对于MaaS系统20的该实施例，假设移动服务提供商具有用户管理功能23(具有用于客户服务的网络服务器或云)和用户简档管理功能23a以及乘客旅程管理功能23b。它还具有区块链管理功能24。具有区块链管理功能24a的区块链功能24与其他实体部分的区块链管理功能25通信。如果预订中心26提供座位预订/拼车预订，则提供中央预订服务器/云。

终端用户与其自己的终端(即，在该实施例中为智能电话21)进行通信，该终端具有示例性的用户界面和传感器，例如GNSS、NFC等。

从图4也可以看出，终端用户可以例如通过终端或通过代理22执行以下动作：服务订购/购买一日/一周票证；预订火车，预订汽车/乘车份额；运输上船/下车许可/记录；下车后进行后处理(例如客户调查、退款或延误赔偿)等。

用户简档管理功能23a被配置为存储静态数据，例如姓名，年龄，联系地址，付款方式(例如信用卡)，服务订购状态，交通偏好，任何其他唯一ID(如TMEI)等，并与终端21通信。

乘客旅程管理功能23b被配置为执行若干动作并与终端21通信。例如，对于多式联运通行证，例如，它要求订购MaaS每月服务，并购买一日票证，一周票证等。关于旅程计划(或旅程计划者)，它提供目的地，路线选择/交通选项，预订/旅行安排并发行票证和发行票证ID，为乘客生成行程并发行行程ID等。在乘客/用户的旅途中，乘客旅程管理功能被配置为开始旅程，并针对旅程的每个部分(迭代)检查通行证/票证持有量并记录堤岸，记录下车并将旅程日志添加到区块链，并在旅程结束时终止旅程并结束行程。

区块链管理功能24a与乘客旅程管理功能23b和其他区块管理25通信。它被配置为添加、验证/执行共识协议并读取区块链。此外，从图4也可以看出，至少在乘客旅程管理功能23b和区块链管理功能24a之间以及在区块链管理功能24a与另一个区块链管理25之间传递通行证、票证和旅程日志信息。

在下文中，参考图5来说明包括乘客旅程历史的区块链30的实施例。

如同参考图1通常解释的那样，区块链30具有几个块30a，30b，30c，其中在图5中，示例性地示出过去的块30a(块#N-1)，当前块30b(块#N)和成功或下一/将来块30c(块#N+1)。

块30a，30b和30c中的每一个可在最大给定块大小内和相关数据结构内包括一个或多个交易中的乘客日志。在图5中，左侧的块30a(块#N-1)处理两个乘客日志31a和31b。从N-1块30a输出的哈希被提供给下一个N块30b(当前块)。块30b(块#N)处理乘客A和B的下一个旅程日志32a和32b，以及乘客C旅程的旅程日志32c。例如，如果乘客D发布了新的旅程日志，但是如果同时超过了区块大小限制，则将在下一个区块(即，在本示例中的方框30c)中处理另一个旅程日志，其中包括乘客B的另一个旅程日志33a条目，乘客C的另一个旅程日志条目3cb和乘客D的另一个旅程日志33c条目，这样，区块30c(块N+1)处理乘客C和D的下一次旅程以及乘客D的剩余日志。然后，将哈希输出(N+1)提供给下一个块(N+2)(图5中未示出)。

通常，区块链30中的旅程日志可以包括以下信息中的至少一个：

-发行者：多式联运通行证发行者，移动服务提供商/运输运营商，乘客ID(匿名数据)。

-票证信息：票证类型，运输类型(铁路，乘车共享等)，座位预订(火车/座位号)，价格或票证，条款和条件。

-登船记录：堤岸的位置，时间/日期，下车的位置，时间/日期，未使用/已使用。

-备注：特别说明(例如，取消，延迟)。

如所提及的，一些实施例涉及提供分布式分类账或区块链的节点拓扑和(通信)网络，其中在一些实施例中，通信网络提供良好的弹性、性能和低成本。

通常，已知并建议(例如，在“区块链及其以外：编码21世纪运输”中，可在https://www.itf-oecd.org/sites/default/files/docs/blockchain-and-beyond-encoding-21st-century-transport.pdf中检索)采用具有分布式网络/分类账的一般结构，根据该结构，多个节点彼此互连，例如互联网就是这种情况，其中的哲学是开放式交换，分布式部署并彼此连接，并且示例性地提出在互联网上具有公共区块链。

然而，已经认识到，甚至可以在互联网或类似(公共)网络中提供的这种公共区块链在一些实施例中可能不是理想的，例如，由于以下原因中的至少一个：节点不直接链接到另一节点。互联网中有很多跃点(可能被用于例如攻击等)，节点的处理能力可能低于预期；节点可能不受信任，任何人都可以加入公共区块链以达成共识，等等。

同样如上所述，通常，已知有各种类型的区块链，对于加密货币，建议使用公共区块链。

然而，在公共区块链中，终端用户可以自由添加/读取区块，且任何人都可以加入交易验证(工作量证明)。在公共链中，组织者不必为区块链准备自己的基础架构，因为互联网中的某人希望通过其硬件加入工作量证明来获得挖矿报酬。

但是，有人接管交易过程的验证可能会带来51％的攻击风险。为了在公共区块链中提供安全的交易，存在许多限制，例如最大块大小有限，交易验证的处理时间长以及块定义的灵活性较低。这些限制对于不频繁的金融交易(如货币兑换)是可以接受的，但在某些实施例中可能不适用于日常使用的频繁交易。

因此，在一些实施例中，假定用于MaaS的区块链使用许可的区块链。在许可的区块链中，只有获得许可的运营商(组成一个联盟)才能添加/读取区块，并且允许有限的参与者加入交易验证(即与受信任的参与者达成共识)。因此，在某些实施例中，例如，将移动服务提供商组织为联盟，并且仅允许具有相应权限的运营商访问按权限分配的分布式分类账或区块链，而恶意参与者或不诚实参与者不能加入区块链联盟。

在下文中，参考图6解释了用于为MaaS提供(许可的)区块链的通信网络40的实施例。

在弹性方面，通信网络40减轻了单点故障(SPOF)的风险，单点故障通常是系统的薄弱点，例如，对于严重依赖中央服务器的传统系统，系统中可能存在SPOF。

从图6可以看出，通信网络40具有多个节点(或实体)41(大圆圈)，它们与不同的运营商或移动服务提供商相关联(例如MaaS服务提供商、铁路运营商、汽车共享/拼车运营商、自行车共享运营商和公交车运营商)。

此外，有多个乘客42(小圆圈)，它们可以与移动服务提供商的节点41通信。移动服务提供商节点41可以一起为MaaS提供许可的区块链(例如，图5的区块链30)形成通信网络40。

乘客42例如订购由移动服务提供商提供的每月MaaS服务，或者购买多式联运服务的一天/一周通行证，方法是与其终端(如图4的终端21)和相关的移动服务提供商进行通信。

如上所述，移动服务提供商41可以是新的服务提供商，例如MaaS运营商(例如，共享乘车)，自行车共享服务提供商，旅行社，以及诸如运输铁路公司、电车运营商等常规运输运营商。

移动服务提供商41通过通信网络彼此连接，这是一种逻辑连接，其中，运营商或移动服务提供商之间的直接连接不是必需的，但是可能需要低等待时间和高吞吐量。

移动服务提供商的实体或节点41可以具有各种功能，但是有两个主要功能，如上面针对图4所讨论的，即旅客管理功能和区块链管理功能。乘客管理功能支持座位预订，拼车/出租车/汽车租赁/火车座位预订，每月订购或购买一日票证等。像普通的电子商务网站一样，它提供网站或智能手机后端处理的用户界面。

另一方面，在本实施例中，对于终端用户而言，区块链是隐藏的，但是可以由多个移动服务提供商来访问。另外，在本实施例中，在节点41之间实施联盟(许可)区块链，其验证了作为联盟成员的移动服务提供商之间的区块链分类账。

在一些实施例中，基于边缘计算来提供区块链功能，这将在下面更详细地说明。

在5G中，电信网络运营商可以在电信云上提供网络服务功能(或网络应用功能)。除了基本的网络功能，电信运营商还可以基于客户的要求提供增值功能。

在一些实施例中，电信网络运营商可以代表移动服务提供商提供与区块链相关的服务(不限于MaaS)。这意味着在一些实施例中，区块链功能可以与移动服务提供商分离，并由一个或多个电信运营商运营。

图7示出了用于通信网络50的边缘节点区块链处理的实施例。

通信网络50包括电信运营商自己的网络的三个边缘节点51，其提供区块链(例如用于MaaS)。电信运营商可以使用北向API为区块链功能配置(移动)边缘节点51，这也将在下面进一步讨论。

如上面已经针对图6所解释的，通信网络50还具有与不同的移动服务提供商相关联的多个节点52，其可以由乘客53访问(如上所述)。

移动服务提供商通过预定义的API(应用接口)请求从电信运营商的节点52到边缘节点51进行区块链处理。边缘节点51代表移动服务提供商处理区块链相关功能(添加/读取/共识)，并将其传送给其他节点52。边缘节点51之间的链接支持高速/低延迟通信，这在一些实施例中有助于快速区块链处理和大块尺寸处理。

边缘节点51(或节点52)可以基于虚拟化网络，例如基于ETSI NFV规范(ETSI GSNFV 002，V1.1.1(2013-10)，网络功能虚拟化(NFV)；架构框架)提供的网络虚拟化功能。

图8示意性地示出了这样的网络虚拟化功能基础设施60，其可以用于在虚拟化网络下提供如本文中所讨论的区块链功能。

虚拟基础设施60具有网络功能虚拟化基础设施61，其包括虚拟计算、虚拟存储和虚拟网络，其将虚拟化层链接到硬件资源，例如计算硬件、存储硬件和网络硬件。

另外，提供了虚拟功能块62，其包括虚拟网络功能(VNF)VNF 1，...，VNF 3和元素管理系统(EMS)EMS 1，...，EMS 3。

虚拟网络功能(VNF)是网络中的常规功能，且是为诸如核心网络协议的应用提供的。在一些实施例中，VNF用于实现区块链功能。这是在虚拟机或容器上运行的软件。电子心理管理系统(EMS)是VNF的管理功能。

基础设施60还包括NFV管理和编排(MANO)块63，其配置VNF，VNF又处理区块链和针对其的网络(例如，虚拟MESH网络)。

电信运营商可以在区块链功能与外部功能之间提供进行配置，请求，检索结果等的应用接口(API)。

提供区块链功能的另一个实施例是基于移动边缘计算(MEC)的，如参考图9所示，图9示出了ETSI移动边缘计算架构70(另见ETSI GS MEC003V1.1.1(2016-03)，移动边缘计算(MEC)；框架和参考体系结构)。

架构70包括不同的网络，例如3GPP网络、本地网络和外部网络。在图9的该层之上，图示了移动边缘主机级，该级包括由移动边缘主机级管理器71管理的移动边缘主机71。

移动边缘主机71具有例如图8所示的虚拟化基础设施(NFVI)，几个移动边缘应用和移动边缘平台被布置在图9中的NFVI之上。

在图9的顶部，示出了移动边缘系统级，其中移动边缘系统级管理，UE和第三方装置位于其中。

可从互联网或电信运营商的网络(例如SD-WAN，软件定义的广域网)访问MEC 70上提供的区块链功能。

此外，区块链用于NFV网络，例如节点身份验证/不变配置日志等。

图10中示出了用于边缘计算的通信网络80的实施例，其提供了区块链功能。

网络80提供在移动边缘计算节点82处提供的几个区块链功能实例81，这些移动边缘计算节点又位于基站接入点83处。用户84通过接入点83访问网络80。

此外，提供了一个用户管理实例85，该实例也位于接入点82处。

总体编排器86管理网络80的功能。

电信运营商可以根据需要创建新实例，例如由网络中心或云中的通信节点提供的常规网络功能。如果节点的容量过紧，则在常规网络中，执行负载平衡(将过程移至其他轻负载节点)或自动缩放(即根据需求增加过程)并不容易。

在边缘计算中，并且因此，在当前网络80中，实例可以由编排器86按需生成，并且如果需要，可以移动到其他节点，例如节点82。过程的物理位置可能靠近终端用户，例如用户84。不同节点82之间的通信可以是低延迟且可靠的。

因此，在网络80的实施例中，区块链的处理负荷不太可能成为瓶颈。

因此，基于虚拟网络和基于边缘计算的区块链可以提供以下至少一项：节点和灵活拓扑(例如网状网络)之间的虚拟直接链接，由于虚拟网络配置/软件定义的网络，由于基于云的处理，节点的处理能力可能会很高，而由于受信任节点的处理，节点的安全性可能会很高。

在一些实施例中，基于云计算来提供分布式分类账或区块链，如将在下面解释的。

通常，各种类型的云计算是已知的，并且图11示出了不同区块链之间的云计算的示例，其中提供了公有云、私有云和移动边缘计算云，每个云被配置为提供区块链功能。云可以彼此通信区块链和/或可以访问不同的区块链。

在一些实施例中，以上讨论的移动边缘计算能够在CPU和网络方面提供快速处理能力。顺便说一句，由于一些实施例中的存储限制，它可能不适合长时间保留分布式分类账。特别是对于MaaS实施例，MaaS旅程记录的数据量可能更大。

另一方面，公有云通常能够处理大量数据，大容量存储以及大数据处理。因此，在该实施例中，分布式分类账的后处理可以由公有云来处理。例如，当移动服务提供商或地方政府可能需要运输统计信息时，可以在公有云上处理区块链。

私有云成本高且容量有限。但是，它提供了高安全性，因此，在该实施例中，它适用于隐私敏感数据或关键数据。

例如，汽车行业可能具有用于自动驾驶或汽车共享、车队管理的私有云，因此，相应的区块链可以由私有云处理。

在一些实施例中，基于智能合约提供了对区块链的详细访问控制。智能合约是附加在区块链上的软件代码，如果满足某些预定义条件，则会执行其特定软件。

不同类型的云/不同类型的应用可以根据基于智能合约的条件访问区块链。

相反，在常规的中央数据库中，数据只是数据，数据管理者为访问控制分配数据库的访问权限。但是，在本实施例中，区块链本身具有该功能(云之一或全部云)。

在下文中，将解释移动服务提供商之间的收入份额概念的实施例，其至少部分地提供简单和准确的收入份额及其与分布式分类账或区块链的计算方法。

图12示出了用于收入份额的方法的第一实施例。这里，提供了收入池90，其从多个移动服务提供中收集收入。

在该实施例中，净销售额是指用于多运营商移动服务的票证或订购的票证发行者的总收入。

净服务交付是指运营商提供的全部服务。大型移动服务提供商(例如，铁路公司)可以拥有或同时提供销售票证和向乘客提供服务，在这种情况下，净销售额和净服务交付之间的差额，如果有盈余，则放入收入池90，如果有负收入，则放入收入池90。

在图12中，第一通行证发行者#1具有第一净销售额，且第二通行证发行者#2具有第二(较小)净销售额。类似地，第一服务提供商A提供第一净服务交付的量，且第二服务提供商B提供第二(较小)的净服务交付的量。如上所述，在该实施例中，通行证发行者和服务提供商是移动服务提供商。

在该实施例中，在分布式分类账或区块链中，多个票证发行者之间的净销售额的总和总是与多个服务提供商之间的净服务交付的总数总和(或相对应)相同，因为区块链是在多个参与者之间是通用的，例如，所有移动服务在联盟中提供，并且每个参与者使用相同的内容分类账进行计算。

图13示出了净销售额计算的方法100的流程图。该方法在101处开始。

在102处，每个通行证发行者读取区块链中的数据(例如，旅程日志数据)并在其中找到通行证发行者ID。

在103处，通行证发行者检查找到的通行证发行者ID是否与自己的ID相同，且如果是这种情况，则在此之后，在104处，将票证价格的金额加到净销售额中，或者如果该ID是不一样，方法在105处结束。

对于净服务交付，提供了一种使用相同原理进行计算的类似方法。

基于图14中的流程图，示出了用于负责票证发行和移动服务交付的运营商的收入份额的方法110，其中服务提供商/运输运营商(即移动服务提供商)计算区块链的净销售额和净服务交付。

该方法在111处开始，并且如针对图14所述，在112处，通行证发行者读取区块链数据中的通行证发行者ID，在113处对其进行检查，并在114处将其净销售额相加，如图13已经讨论的。

在115处，移动服务提供商在块链中读取数据中的移动服务提供商ID，并在116处用其自己的ID对其进行检查。如果找到相同的ID，则在117处添加净服务交付，否则该方法前进至118。

在118处，从(总)净销售额中减去(总)净服务交付。

在119处，如果净销售额大于服务交付本身，则将差额加到收入池中，否则，即，在相反情况下，由移动服务提供商将差额要求到收入池中。

图15示出了存储旅程日志/数据的区块链中的数据结构的示例，其中在图15中示出了三个块125a，125b和125c(块N，N+1和N+2)。不同旅程日志的点密度表示当点密度相同时，多式联运通行证的相同发行者(通行证发行者#1、#2或#3)。三个块125a，125b和126是连续的块。

块125a(#N)具有三个旅程日志126a，126b和126c，其中第一旅程(126a)的票证是由通行证发行者#1为乘客A(交通服务提供商A)发行的。

然后，乘客A乘坐由移动服务提供商A提供的交通工具，其中该交通工具的价格是10欧元。

类似地，乘客B在块125a(#N)的第二次旅程的票证由通行证发行者#2发行，可从第二次旅程日志126b中获取。然后，乘客B乘坐由移动服务提供商B提供的交通工具，其中，该交通工具的价格为20欧元。。

乘客C在块125a(#N)的第三次旅程的票证由通行证发行者#1发行，可从第三次旅程日志126c获取。然后，乘客C乘坐由移动服务提供商C提供的交通工具，其中，该交通工具的价格为30欧元。

类似地，该链在块125b和125c中继续，可以从图15和图16中获取。

图16示出了显示不同的销售和交付成本/价格的表，其由不同的通行证发行者和移动服务提供商为不同的块N、N+l和N+2以及最后一列中的总销售/交付提供。

参考图16，第一次旅程的票证由通行证发行者#1发行，价格为10欧元。然后，乘客乘坐由移动服务提供商A提供的交通工具，其中该交通工具的价格为10欧元。

这意味着通行证发行者#1欠移动服务提供商A10欧元。

然而，在某些实施例中，在任何时候，都不需要在通行证发行者#1和移动服务提供商A之间兑换货币。相反，通行证发行者#1只是在块N+1和N+2中继续进行此过程，且最后，通行证发行者#1欠其他移动服务提供商110欧元，如图16最后一列所示。

其他通行证发行者#2和#3也执行相同的计算，并因此，通行证发行者#2欠200欧元，而通行证发行者#3欠140欧元(请参见图16的最后一列)，其是总计450欧元，因此欠移动服务提供商A，B和C总计450欧元。从图16可以看出，移动服务提供的总索赔额为450欧元，因此所欠的收入金额和可以要求偿还的收入金额相互平衡(净额为零)。

通行证发行者仅需关心净销售额的自己的一部分。通行证发行者不必关心其他通行证发行者计算/移动服务提供商计算是否正确。分布式分类账/区块链与其他通行证发行者和移动服务提供商共享，从而在所有意义上，所有移动服务提供商都可以访问整个信息(即包括本示例中的通行证发行者和移动服务提供商)。

换句话说，分类账/区块链上的收入/成本值始终保持一致。

从通行证发行者的角度来看，他们只需计算欠某人的欠款总和，然后将其计入收入池。

从移动服务提供商的角度来看，他们只是计算自己的索赔额之和。但是，提供运输服务的移动服务提供商将其从收入池中提取。

因此，如图16所示，以这种方式使用区块链/分布式分类账可以提供一个简单的计算方法，因为总的净销售额之和与服务交付净额之和相互对应，并且可以平衡：

所有通行证发行者的净销售额之和：110+200+140＝450

所有移动服务提供商提供的服务总和：120+180+150＝450

因此，在一些实施例中，通过使用区块链，无需中央组织(即银行)即可在通信网络中的对等/节点之间进行直接金融交易。

然而，与已知的对等转移相比，调整可能并不简单，因此，在以下实施例中，讨论了解决谁应该向谁支付以及支付多少的问题的实施例。

原则上，盈余成员应将资金转移给短缺成员以进行平衡。以下实施例允许减少交易数量。

图17示出了一个实施例，其中，收入与服务交付的量成比例地分成份额。

在此实施例中，每个净销售额持有人(图17上方的通行证发行者#1，#2和#3)将收入转移到所有服务交付的持有人(服务提供商/运输运营商A，B和C，图17的下侧)。

每个通行证发行者将根据份额的收入转移给声明服务的提供商，或者是声明收入的服务提供商根据与其他服务提供商的服务交付的量来分享收入。

盈余的通行证发行者收集广播/转移的服务交付的量，并计算其比率(例如百分比)。

使用图16的表的示例编号，如果A，B，C的服务交付的量为180、150和120，则A：B：C的比率＝180：150：120＝40％：33.3％：27％。

因此，如果通行证发行者#2有200欧元，他根据比率分配收入，即200×0.4给服务提供商A，200×0.33给服务提供商B，200×0.27给服务提供商C＝80欧元、66欧元和54欧元。

但是，交易数量可能很大。例如，如果有M个通行证发行者和N个服务提供商，则交易数量可以等于M×N个组合。

在图18所示的另一实施例中，搜索相同量的匹配。

就实现较少数量的交易而言，最有效的方法是找到相同数量的剩余对等方和短缺对等方。对于该实施例，假定在移动服务提供商(包括服务提供商和通行证发行者)的联盟中存在相同数量的净销售额和服务交付。

首先，每个对等方或节点向其他对等方或节点广播剩余或不足的数量。接收到该信息的对等方发现相同数量的对等方。如果幸运地找到了一个合适的对，则剩余的对等方支付给对应的短缺对等方，在这种情况下，双方可以仅因一笔交易而被抵消。在图18中，针对与服务提供商C等的净服务交付相对应的通行证发行者#1的净销售额进行了说明。但是，实际上，要找到一个完全相同的金额可能并不容易。

因此，在一些实施例中，首先尝试该方法，然后将其更改为另一种方法，例如图19所示的方法，下面将对此进行说明。

在图19中，代理从所有通行证发行者那里收集所有净销售额，并将收入分配给服务提供商。

在一些实施例中，代理被指定给收入池。

代理从其他盈余对等方收集所有盈余，如图19中的通行证发行者#1，#2和#3。

短缺对等方，即图19中的服务提供商A，B和C，向代理对等方声明了自己的短缺量。

在其他实施例中，代理可以由第三方(例如银行服务器)提供，或者可以在对等方之间确定。例如，最高盈余的对等方成为代理，并收集其他盈余并进行分配。但是，在某些实施例中，代理可能是系统的瓶颈。

图20示出了具有修改的代理的实施例，其中，总是有最高剩余对等方成为领导者，该领导者是图20中的通行证发行者#1，并向其他短缺对等方，即图20中的服务提供商A和B进行支短缺量少的同行优先，然后抵消。在图20中，然后通行证发行者#2成为领导者，并转入通行证发行者#3，后者成为下一个领导者，然后向剩余的服务提供商C付款。

因此，如果不可能一次性支付，则剩余金额将转移到第二个最高盈余对等方。然后，第二个对等方成为领导者，并向短缺对等方付款。这个过程反复进行，直到净销售额和净交付量达到平衡。

在一些实施例中，以上示例被扩展到不同区域中的国际MaaS运营或MaaS运营。然后将区块链定义为多层结构。第一层区块链配置在国家之间或区域之间，且第二层区块链配置在区域的联盟中。例如，区域联盟中的代表性提供商可以加入第一层区块链并处理国际服务。

总结，在一些实施例中，分布式分类账/区块链提供了多个实体之间的数据库的一致性，而无需中央实例。

在常规的收入份额方式中，服务提供商通常将交易记录在中央数据库中，而主计算机为每个提供商计算收入份额。这样的集中式系统通常很复杂并且涉及高成本。对于像铁路公司这样的大型出行服务提供商来说，加入它可能是负担得起的，但是对于像自行车共享公司这样的小型提供商来说，加入它可能会太昂贵。在一些实施例中，分布式分类账/区块链可以提供分散且低成本的系统。

另一种常规方式是，每个服务提供商诚实地要求为收入份额池要求的服务交付的量。但是，如果每个服务提供商的计算不一致，则很难验证计算。服务提供商可能很难进行交叉检查，因为提供商不太可能保留/共享其他提供商的数据库。即使提供商是诚实的，也可能发生错误的输入或机器故障。这也可能是导致不一致的原因。在某些实施例中，分布式分类账/区块链可以提供强大而准确的数据库系统。

基于集中式服务器的MaaS，例如W02018/042078A1，要求运输运营商之间有一个公用的中央服务器来记录旅程历史。除了高昂的中央服务器部署成本外，中央服务器可能会关闭或出现性能问题。

另一种常规方式是，每个运输运营商都有自己的数据库来发行自己的票证。如果在多个MaaS运营商之间提供服务，则存在MaaS服务器之间数据库不一致的风险，因为未与运营商共享数据。确定他人数据库的日期并不容易。

然而，在一些实施例中，实现了具有区块链的分布式分类账技术(DLT)，其是与多个移动服务提供商共享的分布式数据库。在某些实施例中，联盟的任何成员都可以添加/读取块，并在所有联盟成员之间共享同一块。因此，原则上，在一些实施例中，传输操作者之间的数据不一致是不可能的(不可变的)，因为如果区块链的数据内容存在不一致，则哈希函数的输出将不匹配。此外，在一些实施例中，DLT本质上提供高可用性，可靠性和安全性。

在下文中，参考图21描述通用计算机130的实施例。可以实现计算机130，使得其可以基本上用作任何类型的网络设备，例如基站或新的无线电基站，发送和接收点或通信设备，例如用户设备，终端(end，terminal)设备或如本文所述。计算机具有组件131至141，其可以形成电路，诸如本文所描述的网络设备和通信设备的电路中的任何一个。

可以将使用软件、固件、程序等来执行本文所述方法的实施例安装在计算机130上，然后将其配置为适合于具体实施例。

计算机130具有CPU 131(中央处理单元)，其可以例如根据存储在只读存储器(ROM)132中、存储在存储器137中并加载到随机存取存储器(RAM)133中、存储在可插入到相应驱动器139中的介质140上的程序等，执行如本文所述的各种类型的过程和方法。

CPU 131，ROM 132和RAM 133与总线141连接，该总线又连接到输入/输出接口134。CPU、存储器和存储装置的数量仅是示例性的，并且技术人员将理解，当计算机130用作基站或用户设备(终端)时，计算机130可以进行相应地修改和配置，以满足出现的特定要求。

在输入/输出接口134处，连接了多个组件：输入135，输出136，存储器137，通信接口138和驱动器139，介质140(压缩光盘、数字视频光盘、紧凑型闪存等)可以插入其中。

输入135可以是指示器设备(鼠标，图形表等)，键盘，麦克风，照相机，触摸屏等。

输出136可以具有显示器(液晶显示器，阴极射线管显示器，发光二极管显示器等)，扬声器等。

存储器137可以具有硬盘，固态驱动器等。

通信接口138可以适于例如经由局域网(LAN)，无线局域网(WLAN)，移动电信系统(GSM，UMTS，LTE，NR等)，蓝牙，红外等进行通信。

应当注意，以上描述仅涉及计算机130的示例配置。可以使用附加或其他传感器，存储设备，接口等来实现替代配置。例如，通信接口138可以支持除了提到的UMTS，LTE和NR之外的其他无线电接入技术。

当计算机130用作基站时，通信接口138可以进一步具有相应的空中接口(例如提供E-UTRA协议OFDMA(下行链路)和SC-FDMA(上行链路))和网络接口(实现例如S1-AP，GTP-U，S1-MME，X2-AP等协议)。此外，计算机130可以具有一个或多个天线和/或天线阵列。本公开不限于这种协议的任何特征。

参考图22，讨论了用于实现本公开的实施例的用户设备UE 150和eNB 155以及UE150和eNB 155(或NR eNB/gNB)之间的通信路径154的实施例。UE 150是通信设备的示例，而eNB是基站(即，网络设备)的示例，而在这方面不限制本公开。

UE 150具有发射机151，接收机152和控制器153，其中，通常，发射机151，接收机152和控制器153的技术功能是技术人员已知的，因此，省略它们的更加详细描述。

eNB 155具有发射机156，接收机157和控制器158，其中，一般来说，发射机156，接收机157和控制器158的功能在此也是技术人员已知的，因此省略它们的更详细描述。

通信路径154具有从UE 150到eNB 155的上行链路路径154a和从eNB 155到UE 150的下行链路路径154b。

在操作期间，UE 150的控制器153控制在接收机152处在下行链路路径154b上的下行链路信号的接收，并且控制器153控制经由发射机151在上行链路路径154a上的上行链路信号的传输。

类似地，在操作期间，eNB 155的控制器158控制在发射机156上的下行链路路径154b上的下行链路信号的传输，并且控制器158控制在接收机157处的上行链路路径154a上的上行链路信号的接收。

如从描述中显而易见的，进一步总结，一些实施例涉及用于提供分布式分类账的通信网络，其包括被配置为向其他节点提供分布式分类账功能的至少一个节点。

该通信网络可以被配置为电信网络，其中该电信网络可以被配置为移动电信网络。该至少一个节点可以是电信网络的边缘节点，其中该至少一个节点可以提供应用编程接口，并且其中该通信网络可以进一步被配置为按需提供边缘节点。

可以基于虚拟网络功能来提供分布式分类账功能。通信网络可以进一步包括用于配置分布式分类账功能的编排器。虚拟网络功能可以基于虚拟基础设施。

通信网络可以进一步包括至少一个另外的节点，其中，该节点彼此虚拟链接。

可以基于智能合约来授予对分布式分类账的访问。

分布式分类账可以包括区块链。

分布式分类账可以包括用于移动即服务的数据。

向其提供分布式功能的其他节点可以是联盟的一部分，并且可以基于许可来提供分布式分类账功能。

一些实施例涉及一种提供移动即服务的方法，其可以基于通信网络来实现，该方法包括在多个节点上维护分布式分类账，其中，分布式分类账包括使用移动即服务的用户的旅程数据。

分布式分类账可以包括区块链，其中，区块链可以包括多个块，该块包括旅程数据。

该方法可以进一步包括提供对分布式分类账的访问，其中可以基于许可权来授予对分布式分类账的访问。

该方法可以进一步包括提供用户简档管理功能、乘客旅程管理功能和分布式分类账管理功能中的至少一项。

用户简档管理功能可以包括存储用户信息，其中，用户信息可以包括用户的姓名和出生日期中的至少一个。

用户简档管理功能可以包括故事支付信息，其中支付信息可以包括信用卡信息和银行账户信息中的至少一项。

用户简档管理功能可以包括存储订购信息，其中，订购信息可以包括订购服务和通行证信息中的至少一项。

乘客旅程管理功能可以包括用于座位预订、交通工具共享安排和交通工具预订中的至少一项的预订功能。

乘客旅程管理功能可以包括将旅程数据发送到区块链管理功能。

乘客旅程管理功能可以包括确定或存储用户的行程的当前状态。

该确定可以包括从用户的设备接收信息，其中该设备是终端用户终端或传感器。

分布式分类账管理功能可以包括将数据添加到分布式分类账或从分布式分类账读取数据。

分布式分类账管理功能可以包括执行共识协议，其中共识协议可以基于实用拜占庭式容错。

该方法可以进一步包括提供收入，其中提供收入可以包括计算移动即服务的移动服务提供商的收入金额。

可以基于服务交付的量来计算收入金额。

可以通过搜索具有与收入金额相对应的盈余的另一移动服务提供商来平衡收入金额。

移动服务提供商可以包括在联盟中。

可以从收入池中提供收入金额。

该方法可以进一步包括从移动服务提供商处收集盈余并将其提供给收入池。

收入金额可以由具有最高盈余的移动服务提供商提供。可以基于净销售额的总和来计算收入金额。

净收入的总和可以与标识(例如，乘客，移动服务提供商等)相关联。

可以基于服务交付的总和来计算收入金额。

服务交付的总和可以与移动服务提供商标识相关联。

一些实施例涉及网络设备，例如基站，eNodeB等，其具有被配置为在多个节点上维护分布式分类账的电路，其中分布式分类账包括使用移动即服务的用户的旅程数据。

如上所述，分布式分类账可以包括区块链，其中，区块链可以包括多个块，该块包括旅程数据。可以进一步配置该电路以提供对分布式分类账的访问。可以基于许可权来授予对分布式分类账的访问。该电路可以进一步被配置为提供用户简档管理功能、乘客旅程管理功能和分布式分类账管理功能中的至少一项。用户简档管理功能可以包括存储用户信息。用户信息可以包括用户的姓名和出生日期中的至少一个。用户简档管理功能可以包括故事支付信息。支付信息可以包括信用卡信息和银行账户信息中的至少之一。用户简档管理功能可以包括存储订购信息。订购信息可以包括订购服务和通行证信息中的至少一项。乘客旅程管理功能可以包括用于座位预订、交通工具共享安排和交通工具预订中的至少一项的预订功能。乘客旅程管理功能可以包括将旅程数据传输到区块链管理功能。乘客旅程管理功能可以包括确定或存储用户的行程的当前状态。该确定可以包括从用户的设备接收信息，其中该设备是终端用户终端或传感器。分布式分类账管理功能可以包括将数据添加到分布式分类账或从分布式分类账读取数据。分布式分类账管理功能可以包括执行共识协议。共识协议可以基于实用拜占庭式容错。该电路可以进一步被配置为提供收入。提供收入可以包括计算移动即服务的移动服务提供商的收入金额。可以基于服务交付的量来计算收入金额。可以通过搜索具有与收入金额相对应的盈余的其他移动服务提供商来平衡收入金额。移动服务提供商可以包括在联盟中。可以从收入池中提供收入金额。该电路可以进一步被配置为从移动服务提供商处收集盈余并将其提供给收入池。收入金额可以由具有最高盈余的移动服务提供商提供。可以基于净销售额的总和来计算收入金额。净销售额的总和可以与标识相关联。可以基于服务交付的总和来计算收入金额。服务交付的总和可以与移动服务提供商标识相关联。

一些实施例涉及通信设备，诸如用户设备，(终端)终端设备等(例如，移动电话，智能电话，计算机，膝上型计算机，笔记本等)，其具有被配置为访问多个节点上的分布式分类账的电路，其中该分布式分类账使用移动性作为服务来躲避用户的旅程数据。

如上所述，分布式分类账可以包括区块链，其中，区块链可以包括多个块，该块包括旅程数据。该电路可以被进一步配置为维护分布式分类账。

(82)根据(78)至(81)中任一项的通信设备，其中，基于许可权来授予对所述分布式分类账的访问。该电路可以进一步被配置为提供用户简档管理功能、乘客旅程管理功能和分布式分类账管理功能中的至少一项。用户简档管理功能可以包括存储用户信息。用户信息可以包括用户的姓名和出生日期中的至少一个。用户简档管理功能可以包括故事支付信息。支付信息可以包括信用卡信息和银行账户信息中的至少之一。用户简档管理功能可以包括存储订购信息。订购信息可以包括订购服务和通行证信息中的至少一项。乘客旅程管理功能可以包括用于座位预订、交通工具共享安排和交通工具预订中的至少一项的预订功能。乘客旅程管理功能可以包括将旅程数据传输到区块链管理功能。乘客旅程管理功能可以包括确定或存储用户的行程的当前状态。该确定可以包括从用户的设备接收信息，其中该设备是终端用户终端或传感器。分布式分类账管理功能可以包括将数据添加到分布式分类账或从分布式分类账读取数据。分布式分类账管理功能可以包括执行共识协议。共识协议可以基于实用拜占庭式容错。该电路可以进一步被配置为提供收入。提供收入可以包括计算移动即服务的移动服务提供商的收入金额。可以基于服务交付的量来计算收入金额。可以通过搜索具有与收入金额相对应的盈余的其他移动服务提供商来平衡收入金额。移动服务提供商可以包括在联盟中。可以从收入池中提供收入金额。该电路可以进一步被配置为从移动服务提供商处收集盈余并将其提供给收入池。收入金额可以由具有最高盈余的移动服务提供商提供。可以基于净销售额的总和来计算收入金额。净销售额的总和可以与标识相关联。可以基于服务交付的总和来计算收入金额。服务交付的总和可以与移动服务提供商标识相关联。

如本文所述的方法在一些实施例中还被实现为计算机程序，当在计算机和/或处理器和/或电路上执行时，该计算机程序使计算机和/或处理器和/或电路执行该方法。在一些实施例中，还提供了一种非暂时性计算机可读记录介质，该介质在其中存储了计算机程序产品，当该计算机程序产品由诸如上述处理器的处理器执行时，使得本文所述的方法得以执行。

应该认识到，实施例以方法步骤的示例性顺序描述了方法。但是，方法步骤的特定顺序仅出于说明目的而给出，不应解释为具有约束力。

如果没有另外说明，可以将本说明书中描述的以及所附权利要求书中要求保护的所有单元和实体实现为集成电路逻辑，例如在芯片上，并且如果没有另外说明，则可以通过软件来实现由这些单元和实体提供的功能。

就上述本公开的实施例而言，至少部分地使用软件控制的数据处理设备来实现，应当理解，将提供这样的软件控制的计算机程序以及通过其提供这样的计算机程序的传输，存储或其他介质设想为本公开的方面。

注意，本技术还可以如下配置。

(1)一种用于提供分布式分类账的通信网络，包括至少一个节点，该至少一个节点被配置为：

向其他节点提供分布式分类账功能。

(2)根据(1)的通信网络，其中，通信网络被配置为电信网络。

(3)根据(2)的通信网络，其中，电信网络被配置为移动电信网络。

(4)根据(2)或(3)的通信网络，其中，至少一个节点是电信网络的边缘节点。

(5)根据(4)的通信网络，其中，至少一个节点提供应用编程接口。

(6)根据(4)或(5)的通信网络，其中，通信网络还被配置为按需提供边缘节点。

(7)根据(1)至(6)中任一项的通信网络，其中，基于虚拟网络功能来提供分布式分类账功能。

(8)根据(7)的通信网络，还包括用于配置分布式分类账功能的编排器。

(9)根据(7)或(8)的通信网络，其中，虚拟网络功能基于虚拟基础设施。

(10)根据(1)至(9)中任一项的通信网络，还包括至少一个另外的节点，其中，节点彼此虚拟链接。

(11)根据(1)至(10)中任一项的通信网络，其中，基于智能合约来授权对分布式分类账的访问。

(12)根据(1)至(11)中任一项的通信网络，其中，分布式分类账包括区块链。

(13)根据(1)至(12)中任一项的通信网络，其中，分布式分类账包括用于移动即服务的数据。

(14)根据(1)至(13)中的任一项的通信网络，其中，向其提供分布式功能的其他节点是联盟的一部分。

(15)根据(14)的通信网络，其中，基于许可来提供分布式分类账功能。

(16)一种提供移动即服务的方法，包括：

在多个节点上维护分布式分类账，其中，分布式分类账包括使用移动即服务的用户的旅程数据。

(17)根据(16)的方法，其中，分布式分类账包括区块链。

(18)根据(17)的方法，其中，区块链包括多个块，块包括旅程数据。

(19)根据(16)至(18)中任一项的方法，还包括提供对分布式分类账的访问。

(20)根据(19)的方法，其中，基于许可权来授予对分布式分类账的访问。

(21)根据(16)至(20)中任一项的方法，还包括提供用户简档管理功能、乘客旅程管理功能和分布式分类账管理功能中的至少一项。

(22)根据(21)的方法，其中，用户简档管理功能包括存储用户信息。

(23)根据(22)的方法，其中，用户信息包括用户的姓名和出生日期中的至少一项。

(24)根据(21)至(23)中任一项的方法，其中，用户简档管理功能包括故事支付信息。

(25)根据(24)的方法，其中，支付信息包括信用卡信息和银行账户信息中的至少一项。

(26)根据(21)至(25)中任一项的方法，其中，用户简档管理功能包括存储订购信息。

(27)根据(26)的方法，其中，订购信息包括订购服务和通行证信息中的至少一项。

(28)根据(21)至(27)中任一项的方法，其中，乘客旅程管理功能包括用于座位预订、交通工具共享安排和交通工具预订中的至少一项的预订功能。

(29)根据(21)至(28)中的任一项的方法，其中，乘客旅程管理功能包括将旅程数据发送到区块链管理功能。

(30)根据(21)至(29)中任一项的方法，其中，乘客旅程管理功能包括确定或存储用户的旅行的当前状态。

(31)根据(21)至(30)中的任一项的方法，其中，确定包括从用户的设备接收信息，其中，设备是终端用户终端或传感器。

(32)根据(21)至(31)中任一项的方法，其中，分布式分类账管理功能包括：将数据添加到分布式分类账中或者从分布式分类账中读取数据。

(33)根据(21)至(32)中任一项的方法，其中，分布式分类账管理功能包括执行共识协议。

(34)根据(33)的方法，其中，共识协议基于实用拜占庭式容错。

(35)根据(16)至(34)中任一项的方法，还包括提供收入。

(36)根据(35)的方法，其中，提供收入包括计算移动即服务的移动服务提供商的收入金额。

(37)根据(36)的方法，其中，收入金额是基于服务交付的量来计算的。

(38)根据(36)或(37)的方法，其中，通过搜索具有与收入金额相对应的盈余的另一移动服务提供商来平衡收入金额。

(39)根据(38)的方法，其中，移动服务提供商被包括在联盟中。

(40)根据(36)至(39)中任一项的方法，其中，收入金额是从收入池中提供的。

(41)根据(40)的方法，还包括从移动服务提供商处收集盈余并将其提供给收入池。

(42)根据(36)至(41)中的任一项的方法，其中，收入金额由具有最高盈余的移动服务提供商提供。

(43)根据(36)至(42)中任一项的方法，其中，收入金额是基于净销售额的总和来计算的。

(44)根据(43)的方法，其中，净销售额的总和与标识相关联。

(45)根据(36)至(44)中任一项的方法，其中，收入金额是基于服务交付的总和来计算的。

(46)根据(45)的方法，其中，服务交付的总和与移动服务提供商标识相关联。

(47)一种网络设备，包括电路，该电路被配置为：

在多个节点上维护分布式分类账，其中，分布式分类账包括使用移动即服务的用户的旅程数据。

(48)根据(47)的网络设备，其中，分布式分类账包括区块链。

(49)根据(48)的网络设备，其中，区块链包括多个块，块包括旅程数据。

(50)根据(47)或(48)的网络设备，其中，电路还被配置为提供对分布式分类账的访问。

(51)根据(50)的网络设备，其中，基于许可权来授予对分布式分类账的访问。

(52)根据(47)至(51)中任一项的网络设备，其中，电路还被配置为提供用户简档管理功能、乘客旅程管理功能和分布式分类账管理功能中的至少一项。

(53)根据(52)的网络设备，其中，用户简档管理功能包括存储用户信息。

(54)根据(53)的网络设备，其中，用户信息包括用户的姓名和出生日期中的至少一个。

(55)根据(52)至(54)中任一项的网络设备，其中，用户简档管理功能包括故事支付信息。

(56)根据项(55)的网络设备，其中，支付信息包括信用卡信息和银行账户信息中的至少一项。

(57)根据(52)至(56)中任一项的网络设备，其中，用户简档管理功能包括存储订购信息。

(58)根据(57)的网络设备，其中，订购信息包括订购服务和通行证信息中的至少一项。

(59)根据(52)至(58)中任一项的网络设备，其中，乘客旅程管理功能包括用于座位预订、交通工具共享安排和交通工具预订中的至少一项的预订功能。

(60)根据(52)至(59)中任一项的网络设备，其中，乘客旅程管理功能包括将旅程数据发送到区块链管理功能。

(61)根据(52)至(60)中任一项的网络设备，其中，乘客旅程管理功能包括确定或存储用户的旅行的当前状态。

(62)根据(52)至(61)中任一项的网络设备，其中，确定包括从用户的设备接收信息，其中，设备是终端用户终端或传感器。

(63)根据(52)至(62)中任一项的网络设备，其中，分布式分类账管理功能包括向分布式分类账添加数据或从分布式分类账读取数据。

(64)根据(52)至(63)中任一项的网络设备，其中，分布式分类账管理功能包括执行共识协议。

(65)根据(64)的网络设备，其中，共识协议基于实用拜占庭式容错。

(66)根据(47)至(65)中任一项的网络设备，其中，电路还被配置为提供收入。

(67)根据(66)的网络设备，其中，提供收入包括为移动即服务的移动服务提供商计算收入金额。

(68)根据(67)的网络设备，其中，收入金额是基于服务交付的量来计算的。

(69)根据(67)或(68)的网络设备，其中，通过搜索具有与收入金额相对应的盈余的另一移动服务提供商来平衡收入金额。

(70)根据(69)的网络设备，其中，移动服务提供商被包括在联盟中。

(71)根据(67)至(69)中任一项的网络设备，其中，收入金额是从收入池中提供的。

(72)根据(71)的网络设备，其中，电路还被配置为从移动服务提供商处收集盈余并将其提供给收入池。

(73)根据(67)至(72)中任一项的网络设备，其中，收入金额由具有最高盈余的移动服务提供商提供。

(74)根据(67)至(73)中任一项的网络设备，其中，收入金额是基于净销售额的总和来计算的。

(75)根据(74)的网络设备，其中，净销售额的总和与标识相关联。

(76)根据(67)至(75)中任一项的网络设备，其中，基于服务交付的总和来计算收入金额。

(77)根据(76)的网络设备，其中，服务交付的总和与移动服务提供商标识相关联。

(78)一种通信设备，包括电路，该电路被配置为：

在多个节点上访问分布式分类账，其中，分布式分类账包括使用移动即服务的用户的旅程数据。

(79)根据(78)的通信设备，其中，分布式分类账包括区块链。

(80)根据(79)的通信设备，其中，区块链包括多个块，块包括旅程数据。

(81)根据(78)至(80)中任一项的通信设备，其中，电路还被配置为维护分布式分类账。

(82)根据(78)至(81)中任一项的通信设备，其中，基于许可权来授予对分布式分类账的访问。

(83)根据(78)至(82)中任一项的网络设备，其中，电路还被配置为提供用户简档管理功能、乘客旅程管理功能和分布式分类账管理功能中的至少一项。

(84)根据(83)的通信设备，其中，用户简档管理功能包括存储用户信息。

(85)根据(84)的通信设备，其中，用户信息包括用户的姓名和出生日期中的至少一项。

(86)根据(85)的通信设备，其中，用户简档管理功能包括故事支付信息。

(87)根据(86)的通信设备，其中，支付信息包括信用卡信息和银行账户信息中的至少一项。

(88)根据(83)至(87)中任一项的通信设备，其中，用户简档管理功能包括存储订购信息。

(89)根据(88)的通信设备，其中，订购信息包括订购服务和通行证信息中的至少一项。

(90)根据(83)至(89)中任一项的通信设备，其中，乘客旅程管理功能包括用于座位预订、交通工具共享安排和交通工具预订中的至少一项的预订功能。

(91)根据(83)至(90)中任一项的通信设备，其中，乘客旅程管理功能包括将旅程数据发送到区块链管理功能。

(92)根据(83)至(91)的通信设备，其中，乘客旅程管理功能包括确定或存储用户的旅行的当前状态。

(93)根据(83)至(92)中任一项的通信设备，其中，确定包括从用户的设备接收信息，其中，设备是终端用户终端或传感器。

(94)根据(83)至(93)中任一项的通信设备，其中，分布式分类账管理功能包括：将数据添加到分布式分类账中或者从分布式分类账中读取数据。

(95)根据(83)至(94)中任一项的通信设备，其中，分布式分类账管理功能包括执行共识协议。

(96)根据(95)的通信设备，其中，共识协议基于实用拜占庭式容错。

(97)根据(78)至(96)中任一项的通信设备，其中，电路还被配置为提供收入。

(98)根据(97)的通信设备，其中，提供收入包括计算移动即服务的移动服务提供商的收入金额。

(99)根据(98)的通信设备，其中，收入金额是基于服务交付的量来计算的。

(100)根据(98)或(99)的通信设备，其中，通过搜索具有与收入金额相对应的盈余的另一移动服务提供商来平衡收入金额。

(101)根据(100)的通信设备，其中，移动服务提供商被包括在联盟中。

(102)根据(98)至(101)中任一项的通信设备，其中，收入金额是从收入池中提供的。

(103)根据(102)的通信设备，其中，电路还被配置为从移动服务提供商处收集盈余并将其提供给收入池。

(104)根据(98)至(103)中任一项的通信设备，其中，收入金额由具有最高盈余的移动服务提供商提供。

(105)根据(98)至(104)中任一项的通信设备，其中，收入金额是基于净销售额的总和来计算的。

(106)根据(105)的通信设备，其中，净销售额的总和与标识相关联。

(107)根据(98)至(106)中任一项的通信设备，其中，收入金额是基于服务交付的总和来计算的。

(108)根据(107)的通信设备，其中，服务交付的总和与移动服务提供商标识相关联。

(109)一种计算机程序，其包括当在计算机上执行时使计算机执行根据(16)至(46)中任一项的方法的程序代码。

(110)一种在其中存储计算机程序产品的非暂时性计算机可读记录介质，当该计算机程序产品由处理器执行时，使得执行根据(16)至(46)中任一项的方法。