CN115334014B - 虚拟交换机和数据传输系统 - Google Patents

Abstract

本发明实施例提供一种虚拟交换机和数据传输系统，该虚拟交换机包括：5G通信网络的核心网中的会话管理功能网元和用户面功能网元。会话管理功能接收多个终端设备中一终端设备发送的第一会话建立请求，确定虚拟交换机的预设数据转发容量。之后，用户面功能网元再根据会话管理功能网元发送的、多个终端设备各自对应的第二会话建立请求，分别确定多个终端设备各自的待传输数据。用户面功能网元再根据待传输数据的数据总量以及虚拟交换机的预设数据转发容量，确定待传输数据的传输方式，并按照确定出的传输方式进行传输。上述也即是根据5G通信网络的核心网中的已有网元构成具有预设数据转发容量的虚拟交换机并实现数据传输的过程。

Description

虚拟交换机和数据传输系统

技术领域

本发明涉及通信技术领域，尤其涉及一种虚拟交换机和数据传输系统。

背景技术

近年来，借助应用程序(application，简称APP)，终端设备使用的场景也越来越广泛，比如视频播放场景，自动驾驶场景等等。并且随着网络虚拟化的不断发展，往往可以借助虚拟交换机进行数据传输，使终端设备能够应用到众多场景中。以视频播放场景为例，可以借助虚拟交换机将视频传输至用户使用的终端设备，以使终端设备播放视频。

随着5G通信技术的不断发展，可以使用基于5G通信网络架构构建虚拟交换机，实现不同场景中的数据传输。此时，如何基于5G通信网络架构构建虚拟交换机就成为一个亟待解决的问题。

发明内容

有鉴于此，本发明实施例提供一种虚拟交换机和数据传输系统，用以基于5G通信网络架构构建虚拟交换机，并用其实现数据传输。

第一方面，本发明实施例提供一种虚拟交换机，包括：核心网中的会话管理功能网元和用户面功能网元；

所述会话管理功能网元，用于响应于目标终端设备产生的第一会话建立请求，确定所述虚拟交换机的预设数据转发容量；发送所述目标终端设备对应的第二会话建立请求至所述用户面功能网元；

所述用户面功能网元，用于响应于多个终端设备各自对应的第二会话建立请求，确定所述多个终端设备各自的待传输数据的数据总量，所述多个终端设备包含所述目标终端设备；根据所述数据总量和所述预设数据转发容量，确定所述多个终端设备各自的待传输数据的传输方式，以按照所述传输方式进行数据传输。

第二方面，本发明实施例提供一种虚拟交换机，包括：核心网中的会话管理功能网元和用户面功能网元；

所述会话管理功能网元，用于响应于目标终端设备产生的第一视频数据获取请求，确定所述虚拟交换机的预设数据转发容量；发送所述目标终端设备对应的第二视频数据获取请求至所述用户面功能网元；

所述用户面功能网元，用于响应于多个终端设备各自对应的第二视频数据获取请求，确定所述多个终端设备各自的待传输视频数据的数据总量，所述多个终端设备包含所述目标终端设备；根据所述数据总量和所述预设数据转发容量，确定所述多个终端设备各自的待传输视频数据的传输方式，以按照所述传输方式进行视频数据传输。

第三方面，本发明实施例提供一种数据传输系统，包括：多个终端设备、虚拟交换机以及服务器；所述虚拟交换机包括核心网中的会话管理功能网元和用户面功能网元；

所述多个终端设备中的目标终端设备，用于响应于会话建立操作，生成第一会话建立请求；

所述会话管理功能网元，用于响应于所述第一会话建立请求，确定所述虚拟交换机的预设数据转发容量；发送所述目标终端设备对应的第二会话建立请求至所述用户面功能网元；

所述用户面功能网元，用于响应于所述多个终端设备各自对应的第二会话建立请求，确定所述多个终端设备各自的待传输数据的数据总量；从所述服务器获取所述多个终端设备各自的待传输数据；根据所述数据总量以及所述预设数据转发容量，确定所述多个终端设备各自的待传输数据的传输方式，以按照所述传输方式进行数据传输。

本发明实施例提供的虚拟交换机，在5G通信网络架构中，可以由核心网中的会话管理功能网元和用户面功能网元构成具有预设数据转发容量的虚拟交换机。此时，基于虚拟交换机的预设数据转发容量，其的具体工作过程可以描述为：会话管理功能网元可以接收多个终端设备中的目标终端设备发送的第一会话建立请求。响应于此请求，确定虚拟交换机的预设数据转发容量的同时，发送目标终端设备对应的第二会话建立请求至用户面功能网元。

当用户面功能网元接收到包含目标终端设备在内的多个终端设备各自对应的第二会话建立请求时，用户面功能网元可以响应于此请求，确定多个终端设备各自的待传输数据的数据总量，并根据此数据总量与虚拟交换机的预设数据转发容量之间的大小关系，确定多个终端设备各自的待传输数据的传输方式，以按照传输方式进行数据传输。

通过上述描述可知，可以根据5G通信网络的核心网中的已有网元，即会话管理功能网元和用户面功能网元构成具有预设数据转发容量的虚拟交换机并实现数据传输。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例提供的5G通信网络中核心网的架构示意图；

图2为本发明实施例提供的虚拟交换机应用在视频播放场景下的一种示意图；

图3为本发明实施例提供的虚拟交换机应用在视频播放场景下的另一种示意图；

图4为本发明实施例提供的虚拟交换机应用在视频播放场景下的一种示意图；

图5为本发明实施例提供的一种数据传输系统的结构示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

在本发明实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本发明。在本发明实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义，“多种”一般包含至少两种，但是不排除包含至少一种的情况。

应当理解，本文中使用的术语“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。

取决于语境，如在此所使用的词语“如果”、“若”可以被解释成为“在……时”或“当……时”或“响应于确定”或“响应于识别”。类似地，取决于语境，短语“如果确定”或“如果识别(陈述的条件或事件)”可以被解释成为“当确定时”或“响应于确定”或“当识别(陈述的条件或事件)时”或“响应于识别(陈述的条件或事件)”。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的商品或者系统不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种商品或者系统所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的商品或者系统中还存在另外的相同要素。

在对本发明各实施例提供的虚拟交换机进行说明之前，可以先对使用虚拟交换机的实际意义进行示例性说明：

正如背景技术中所述的，借助安装的APP或者其他数据终端设备可以应用到多种场景中，其中，每种场景又可以包含至少一种服务。在实际应用中，比如借助交换机将视频数据传输到终端设备中，从而使终端设备应用到视频播放场景中。其中，视频数据具体又可以包括在线视频或者直播视频，此在线视频既可以是影视剧等供用户休闲的视频，也可以是用于实现远程教育或者远程医疗的视频。又比如由终端设备即车辆和路测设备可以构成车联网，并且根据车联网中的路测设备采集到的路测数据可以得到导航数据，则借助交换机可以将导航数据车辆中，从而使车辆按照导航数据行驶，实现自动驾驶。

并且随着5G通信技术的发展，不同场景下对应的数据也可以借助5G通信网络进行传输。此时，便可以使用本发明下述各实施例提供的、基于5G通信网络架构构建的虚拟交换机实现数据传输。

并且需要说明的有，上述的视频播放场景和自动驾驶场景只是一种示意，本发明并不对场景进行限定，其可以适用于任何存在数据传输需求的场景。

基于上述描述，下面结合附图对本发明的一些实施方式作详细说明。在各实施例之间不冲突的情况下，下述的实施例及实施例中的特征可以相互组合。另外，下述各方法实施例中的步骤时序仅为一种举例，而非严格限定。

图1为5G通信网络中核心网的基本架构。图1中的核心网可以包括网络暴露功能(Network Exposure Function，简称NEF)网元、策略控制功能(Policy Control Function，简称PCF)网元、统一数据管理功能(Unified Data Management,UDM)网元、会话管理功能(Session Management Function，简称SMF)网元、用户面功能(User Plane Function，简称UPF)网元、接入和移动性管理功能(Access and Mobility Management Function，简称AMF)网元。

则基于图1所示的核心网架构，本发明实施例提供的一种的虚拟交换机可以包括图1中的SMF网元和UPF网元。

在实际中，一台虚拟交换机往往用于向多个终端设备传输数据，则借助一台虚拟交换机进行数据传输的多个终端设备可以认为是一个群组。可选地，群组内的多个终端设备通常处于一个局域网内。并且在该群组中，可以根据终端设备产生第一会话建立请求的先后顺序，将其划分为目标终端设备和非目标终端设备。其中，产生第一会话建立请求表明终端设备和虚拟交互机之间存在数据传输。一种常见的方式，可以将第一个产生第一会话建立请求的终端设备划分为目标终端设备。其中，第一会话建立请求具体可以为PDUSession请求。

基于上述描述，可以由核心网中的SMF网元和UPF网元所构成虚拟交换机，其的工作过程可以具体描述为：

首先，目标终端设备可以生成并发送第一会话建立请求至SMF网元。

其中，此第一会话建立操作可以由目标终端设备的使用者触发。举例来说，当使用者对目标终端设备中安装的应用程序(application，简称APP)触发启动操作或者是内容更新操作，则目标终端设备可以产生第一会话建立请求。可选地，目标终端设备也可以定时的产生第一会话建立请求。并且基于图1所示的核心网架构，目标终端设备产生的第一会话建立请求具体可以依次通过无线接入网RAN、核心网中的AMF网元传输至核心网中的SMF网元。其中，无线接入网具体可以包括5G基站。

接着，SMF网元接收并响应目标终端设备发送的第一会话建立请求，以确定出虚拟交换机的预设数据转发容量，同时也建立自身与目标终端设备之间的传输通道。为了描述简洁，本实施例以及下述各实施例中均将预设数据转发容量简称为预设容量。

其中，虚拟交换机的预设容量表示在单位时间内虚拟交换机能够传输的最大数据量，比如可以设置为5G bit/s，预设容量的大小可以根据实际需求预先设置。可选地，虚拟交换机的预设容量可以预先写入SMF网元中。可选地，当目标终端设备无需获取数据时，目标终端设备还可以产生会话取消请求，此会话取消请求可以借助SMF网元与目标终端设备之间的传输通道进行传输。举例来说，当使用者关闭目标终端设备中的某一APP时，目标终端设备可以产生会话取消请求。

进而，SMF网元还可以响应于第一会话建立请求，建立目标终端设备和UPF网元之间的传输通道，同时还可以根据第一会话建立请求中的设备标识确定目标终端设备对应的待传输数据，也即是需要向目标终端设备传输的数据。

最后，SMF网元在接收到目标终端设备产生的第一会话请求后，还可以生成并发送目标终端设备对应的第二会话建立请求至UPF网元。UPF网元响应于此第二会话建立请求，建立自身与SMF网元之间的传输通道。SMF网元利用此传输通道可以使UPF网元知晓目标终端设备对应的待传输数据，以由UPF网元确定待传输数据的传输方式，并利用目标终端设备与UPF网元之间的传输通道传输目标终端设备的待传输数据。

可选地，UPF网元可以根据目标终端设备的待传输数据的数据量与预设容量之间的大小关系确定传输方式。具体地，若待传输数据的数据量小于或等于预设容量，则UPF网元直接从服务器获取目标终端设备的待传输数据并传输即可。若待传输数据的数据量大于预设容量，则UPF网元可以对目标终端设备的待传输数据进行丢包处理，此时，也即是实现了对目标终端设备的待传输数据的流量控制。

按照上述过程，由5G通信网络的核心网中的SMF网元和UPF网元即可构成虚拟交换机，此虚拟交换机可以根据自身的预设容量，对目标终端设备的待传输数据进行流量控制。

可选地，虚拟交换机在为目标终端设备传输待传输数据后，会占用自身的部分或全部容量，此时，虚拟交换机还可以将自身的剩余容量也可以反馈给终端设备的管理中心，以使管理中心的管理人员了解当前虚拟交换机的使用情况。其中，管理中心可以管理至少一个群组。

可选地，根据上述描述可知，当目标终端设备的待传输数据的数据量超过虚拟交换机的预设容量时，还可以发送相应的通知至终端设备的管理中心，再由管理中心转发通知至目标终端设备，以提醒目标终端设备的使用者，虚拟交换机当前的容量不足，需要对待传输数据进行丢包处理。响应于目标终端设备的使用者触发的继续操作，UPF网元进一步对待传输数据进行丢包处理。

在实际中，在目标终端设备与虚拟交换机之间存在数据传输的同时，群组中的非目标终端设备也可以产生并发送第一会话建立请求至SMF网元。SMF网元在分别建立起自身与非目标终端设备之间的传输通道的同时，也可以确定非目标终端设备各自的待传输数据。其中，非目标终端设备的数量可以为至少一个。

同时，SMF网元也可以向UPF网元发送目标终端设备和非目标终端设备(即多个终端设备)各自对应的第二会话建立请求，之后，UPF网元还可以响应于此第二会话建立请求，计算各终端设备各自的待传输数量的数据总量。并根据数据总量与预设容量之间的大小关系，确定各终端设备对应的待传输数据的传输方式。实际中，第二会话建立请求可以为N4session请求。

具体地，若各终端设备的数据总量小于或等于预设容量，则UPF网元直接传输多个终端设备各自的待传输数据即可。若数据总量大于预设容量，则对多个终端设备各自的待传输数据进行丢包处理，也即是实现了对群组内的多个终端设备进行流量控制。

需要说明的有，上述与虚拟交互机存在数据传输过程的多个终端设备，可以是群组中所有产生第一会话建立请求的终端设备，其的数量小于或等于群组终端设备的总量。

需要说明的还有，SMF网元在接收到目标终端设备产生的第一会话建立请求后，建立的自身与UPF网元之间的传输通道，可以认为是专属于目标终端设备所属群组的，即对于群组内所有与虚拟交换机存在数据传输过程的终端设备，SMF网元都可以借助此传输通道，将终端设备各自的待传输数据的数据量通知至UPF网元，以使UPF网元得到数据总量，进一步确定数据的传输方式。

根据上述描述可知，由核心网中的已有网元构成的虚拟交换机可以根据自身的预设容量实现确定多个终端设备各自的待传输数据的传输方式，并按照此传输方式进行传输。

本实施例中，可以由核心网中的SMF网元和UPF网元构成具有预设容量的虚拟交换机。虚拟交换机的具体工作过程为：SMF网元可以接收多个终端设备中的目标终端设备发送的第一会话建立请求。响应于此请求，确定虚拟交换机的预设容量的同时，发送目标终端设备对应的第二会话建立请求至用户面功能网元。当UPF网元接收到包含目标终端设备在内的多个终端设备各自对应的第二会话建立请求时，UPF网元可以响应于此请求，确定多个终端设备各自的待传输数据的数据总量，并根据此数据总量与虚拟交换机的预设容量之间的大小关系，确定多个终端设备各自的待传输数据的传输方式，以按照传输方式进行数据传输。也即是可以根据5G通信网络的核心网中的已有网元，即SMF网元和UPF网元构成具有预设容量的虚拟交换机并实现数据传输。

根据上述实施例中的描述可知，终端设备的待传输数据的传输方式可以根据虚拟交换机的预设容量确定。而虚拟交换机的预设容量除了可以直接写入SMF网元之外，可选地，还可以存储在核心网中的UDM网元和/或PCF网元中。其中，UDM网元和/或PCF网元也可以认为是虚拟交换机的组成部分。可选地，虚拟交换机还可以包括核心网中的NEF网元。5G通信网络的维护人员可以对NEF网元触发容量配置操作，以借助NEF网元提供的预设接口，将预设容量写入UDM网元和/或PCF网元。上述过程也即是实现了利用核心网中的已有网元定义虚拟交换机的容量。

可选地，SMF网元也提供预设接口，在SMF网元接收到第一会话建立请求后，还可以根据此预设接口，将多个终端设备各自对应的第二会话建立请求发送至UPF网元。其中，SMF网元提供的预设接口具体可以为N4口。

上述实施例中并未对终端设备的待传输数据的具体类型进行限定。当待传输数据具体为视频数据时，包括图1所示的核心网架构中的SMF网元和UPF网元的虚拟交换机可以为终端设备进行视频数据的传输。

首先，群组中的目标终端设备可以响应于使用者针对视频APP触发的操作，从而产生第一视频数据获取请求。接着，SMF网元接收并响应目标终端设备发送的第一视频数据获取请求，以确定出虚拟交换机的预设数据转发容量，同时也建立自身与目标终端设备之间的传输通道。

进而，SMF网元还可以响应于此第一视频数据获取请求，建立目标终端设备和UPF网元之间的传输通道，同时还可以根据第一视频数据获取请求中的设备标识确定目标终端设备对应的待传输视频数据。

最后，SMF网元在接收到目标终端设备产生的第一视频数据获取请求后，还可以生成并发送目标终端设备对应的第二视频数据获取请求至UPF网元。UPF网元响应于此第二视频数据获取请求，建立自身与SMF网元之间的传输通道。SMF网元则可以利用此传输通道将目标终端设备对应的待传输视频数据通知至UPF网元，以由UPF网元确定待传输视频数据的传输方式，并按照确定出的数据传输方式，利用目标终端设备与UPF网元之间的传输通道，传输目标终端设备的待传输视频数据。

在实际中，除了目标终端设备，群组中的非目标终端设备也可以产生并发送第一视频数据获取请求至SMF网元。此时，SMF网元可以向UPF网元发送目标终端设备和非目标终端设备各自对应的第二视频数据获取请求。之后，UPF网元可以响应于多个第二视频数据获取请求，计算各终端设备各自的待传输视频数量的数据总量。并根据数据总量与虚拟交换机的预设容量之间的大小关系，确定各终端设备对应的待传输视频数据的传输方式，并按照确定出的传输方式分别向不同的终端设备传输视频数据。

其中，在本实施提供的视频数据传输场景中，第一视频数据获取请求即为上述实施例中的第一会话建立请求，第二视频数据获取请求即为上述实施例中的第二会话建立请求。

另外，本实施例中未详细描述的内容可以参见上述实施例中的相关描述，在此不再赘述。

为了便于理解，结合视频播放场景对上述各实施例进行示例性说明，其中，视频数据具体可以为直播视频。

假设，虚拟交换机可以包括核心网中的SMF网元和UPF网元。处于同一5G局域网中的终端设备1～终端设备3可以构成一个群组。终端设备1～终端设备3的使用者分别是用户1～用户3。

在T1时刻，用户1可以打开终端设备1中的直播APP并进入直播间1。此时，终端设备2、3中安装的直播APP还未被打开，终端设备1可以认为是上述实施例中的目标终端设备。终端设备1响应于用户1触发的直播间1进入操作，使终端设备1生成第一会话建立请求。此请求会依次通过无线接入网以及核心网中AMF网元，最终被SMF网元接收到。

SMF网元在接收到第一会话建立请求后，一种可选地方式，能够直接得到预先写入SMF网元中的此虚拟交换机的预设容量，同时建立终端设备1和SMF网元之间的传输通道。另一种可选地方式，还可以借助虚拟交换机中的NEF网元，将预设容量写入虚拟交换机中的UDM网元和/或PCF网元。此时，SMF网元还可以从UDM网元和/或PCF网元中获取预设容量。在本实施例中，预设容量可以为2G bit/s。

在接收到第一会话建立请求后，SMF网元还可以生成并发送终端设备1对应的第二会话建立请求至UPF网元，同时确定终端设备1对应的待传输数据，即直播间1的视频数据。其中，SMF网元可以根据第一会话建立请求中包含的设备标识从保存有直播视频流的服务器确定终端设备1对应的待传输数据。

由于此时UPF网元只收到终端设备1对应的第二会话建立请求，终端设备2、3依旧没有打开直播APP并进入某一直播间，则UPF网元确定直播间1的视频数据量为1G，小于虚拟交换机的预设容量2G，则UPF网元直接将直播间1的视频数据传输至终端设备1，以实现为用户1提供视频播放场景中的直播服务。

在实际中，还可能出现以下情况：当T1时刻用户1进入直播间1后，在T2时间用户2进入了直播间2。

此种情况下，终端设备2即为图1所示实施例中的非目标终端设备。此时，SMF网元同样也会得到终端设备2产生的第一会话建立请求，同时生成并发送端设备2对应的第二会话建立请求至UPF网元。UPF网元可以通过自身与SMF网元之间的传输通道，获知终端设备1对应的待传输数据的数据量为1G，终端设备2对应的待传输数据的数据量为2G。此时，两个终端设备的待传输数据的数据总量为3G大于虚拟交换机的预设容量2G，则UPF可以对两个终端设备各自的待传输数据进行丢包处理。其中，通过丢包可以使待传输数据的数据总量小于或等于2G。而丢包的具体策略可以是随机丢包，可以是根据终端设备的优先级进行丢包。最终，UPF网元会将丢包后剩余的待传输数据发送至相应的终端设备中。

上述过程可以结合图2理解。

承接上述举例，要说明的有，对于由终端设备1～终端设备3构成的群组，群组中的每个终端设备都有可能是目标终端设备或非目标终端设备。具体来说，群组中第一个打开直播APP进入直播间的用户所使用的终端设备即为目标终端设备，后续进入直播间的用户所使用的终端设备即为非目标终端设备，并且目标终端设备和非目标终端设备的数量小于或等与群组内终端设备的数量。

为了便于理解，还可以结合自动驾驶场景对图1所示实施例进行示例性说明。

基于5G通信网络，由车辆、路测设备和服务器可以够构成车联网。车辆网中可以包含车辆1～车辆3。与图2所示实施例类似的，车辆1和车辆2有获取导航数据的需求，则两车辆可以先后产生第一会话建立请求。此时，SMF网元可以根据1车辆的第一会话建立请求，确定虚拟交换机的预设容量是0.2G bit/s。再进一步确定车辆1和车辆2各自的待传输数据分别为0.1G和0.2G。其中，车辆的待传输数据可以为车辆的导航数据。服务器可以根据路测设备采集的路测数据为车辆生成相应的导航数据。

当UPF网元可以接收到车辆1和车辆2各自对应的第二会话建立请求后，可以计算出车辆1和车辆2的导航数据的数据总量为0.3G大于预设容量0.2G，此时，UPF网元会对车辆1和车辆2各自导航数据进行丢包处理，并将处理后的剩余导航数据发送至对应的车辆。

上述过程可以结合图3理解。

正如上述实施例中描述的，虚拟交换机能够传输适用于不同场景中的不同服务的数据，也即是多种服务对应的数据都可以由同一虚拟交换机传输。则根据虚拟交换机传输的数据对应的服务不同，虚拟交换机的预设容量也不同，也即是虚拟交换机的预设容量可以与服务标识存在对应关系。

可选地，对于预设容量和服务标识之间的对应关系，其可以预先写入SMF网元中，也可以响应于5G通信网络的维护人员对NEF网元触发的容量配置操作，借助NEF网元提供的预设接口，将对应关系写入UDM网元和/或PCF网元。也即是实现了利用核心网中已有的网元进行虚拟交换机容量的定义。

其中，服务标识可以表明虚拟交换机产生的数据所对应的服务，即虚拟交换机在将数据传输至终端设备后，终端设备所能向用户提供的服务。

举例来说，群组中的终端设备可以安装有不同的APP，则可选地，服务标识也可以具体认为是APP的标识。

可选地，服务标识也可以表明虚拟交换机所传输的数据的类型。举例来说，终端设备中可以安装有视频APP、直播APP和导航APP。其中，虚拟交换机通过为终端设备传输在线视频，能够使终端设备为用户提供在线视频观看服务；虚拟交换机通过为终端设备传输直播视频，能够使终端设备为用户提供直播服务；虚拟交换机通过为终端设备传输导航数据，能够使终端设备为用户提供导航服务。由于针对直播APP和视频APP，虚拟交换机所要传输的是视频数据，针对导航APP虚拟交换机所要传输的是导航数据，因此，直播APP和视频APP可以认为具有相同的服务标识，二者与导航APP可以认为具有不同的服务标识。

对于存在上述对应关系的情况下，基于图1所示的核心网架构，虚拟交换机的另一种工作过程可以描述为：

当群组中的目标终端设备产生第一会话建立请求后，基于上述的对应关系，SMF网元可以根据接收到的第一会话建立请求中包含的目标服务标识，确定与此目标服务标识对应的预设容量。同时，SMF网元还可以根据第一会话建立请求中包含的设备标识，确定目标终端设备的待传输数据。之后，SMF网元还可以向UPF网元发送目标终端设备对应的第二会话建立请求，以建立起SMF网元和UPF网元之间的传输通道，并通过此通道控制UPF网元将目标终端设备的待传输数据发送至目标终端设备。

在目标终端设备产生第一会话建立请求之后，群组中的其他终端设备即非目标终端设备也可以产生第一会话建立请求。此时，SMF网元可以得到多个终端设备(即目标终端设备和非目标终端设备)产生的第一会话建立请求，并分别根据第一会话建立请求中包含的设备标识，确定每个终端设备的待传输数据。

进一步地，若SMF网元确定出多个终端设备各自产第一会话建立请求中包含的服务标识完全相同，则SMF网元能够得到相同的预设容量。同时针对产生了第一会话建立请求的多个终端设备，SMF网元还会生成各自对应的第二会话建立请求。UPF网元在接收到第二会话建立请求后，可以计算多个终端设备各自的待传输数据的数据总量。

最终，UPF网元可以根据计算出的数据总量与预设容量之间的大小关系，确定不同终端设备的待传输数据的传输方式。

具体地，若计算出的数据总量小于或等于预设容量，则UPF网元直接将多个终端设备各自的待传输数据传输至相应的终端设备即可。若计算出的数据总量大于预设容量，则UPF网元会对各终端设备的待传输数据进行丢包处理，以使丢包后各终端设备的待传输数据的数据总量小于或等于预设容量。

若多个终端设备各自产生第一会话建立请求中包含的服务标识不完全相同，则SMF网元可以确定出多个预设容量。此时，UPF网元计算产生包含相同服务标识的第一会话建立请求的终端设备的待传输数据的数据总量，也计算包含不同服务标识的第一会话建立请求的终端设备的待传输数据的数据量，并分别将其与服务标识对应的预设容量进行比对，看是否需要对待传输数据进行丢包处理。

当服务标识和预设容量之间存在对应关系时，可以继续以结合视频播放场景对虚拟交换机的工作过程仅是说明：

假设，虚拟交换机可以包括核心网中的SMF网元和UPF网元。处于同一5G局域网中的终端设备1～终端设备3可以构成一个群组。终端设备1～终端设备3的分别被用户1～用户3使用。终端设备1～终端设备3中可以安装有直播APP和者导航APP。并且直播APP和导航APP的工作时产生的待传输数据可以借助同一虚拟交换机进行传输。

在T1时刻，用户1可以打开终端设备1中安装的直播APP并进入直播间1。此时，终端设备2、3中安装的APP还都未被打开，则终端设备1可以认为是上述实施例中的目标终端设备。

之后，终端设备1响应于用户触发的直播间1的进入操作，生成第一会话建立请求。SMF网元在接收到第一会话建立请求后，可以根据第一会话请求中包含的设备标识确定出终端设备1的待传输数据。还可以根据第一会话建立请求中包含的服务标识即APP标识，确定出该虚拟交换机与APP标识对应的预设容量为2G bit/s，同时还可以建立终端设备1和SMF网元之间的传输通道。

在接收到第一会话建立请求后，SMF网元还可以生成并发送终端设备1对应的第二会话建立请求至UPF网元，同时确定终端设备1对应的待传输数据，即直播间1的视频数据。其中，SMF网元可以从保存有直播视频流的服务器处确定终端设备1对应的待传输数据。

可选地，在本实施例中，服务标识与预设容量之间的对应关系可以存储于SMF网元中。还可以借助虚拟交换机中的NEF网元，将服务标识与预设容量之间的写入虚拟交换机中的UDM网元和/或PCF网元。之后，SMF网元还可以从UDM网元和/或PCF网元中获取预设容量。

此时，由于UPF网元只收到终端设备1对应的第二会话建立请求，终端设备2、3还没有打开直播APP进入某一直播间，UPF网元可以确定直播间1的数据视频数据量为1G，小于虚拟交换机针对直播服务的预设容量2G，则UPF网元直接将直播间1的视频数据传输至终端设备1，从而为用户1提供视频播放服务，更具体说是直播服务。

在实际中，还可能出现以下情况：当T1时刻用户1进入直播间1后，T2时间，用户2也可以进入直播间2，在T3时间，用户3开启导航APP。

此种情况下，终端设备2和终端设备3可以认为是图1所示实施例中的非目标终端设备。SMF网元同样也会得到终端设备2和终端设备3产生的第一会话建立请求，并根据APP标识与预设容量之间的对应关系，确定出对于直播服务，虚拟交换机的预设容量为2G，对于导航服务，虚拟交换机的预设容量为1G。

同时SMF网元还会生成并发送两终端各自对应的第二会话建立请求至UPF网元。UPF网元可以通过自身与SMF网元之间的传输通道，获知终端设备1的待传输数据的数据量为1G，终端设备2的待传输数据的数据量为2G，终端设备3的待传输数据为0.5G。此时，终端设备1和终端设备2各自对应的第一会话建立请求具有相同的服务标识，则UPF网元计算二者的待传输数据的数据总量为3G大于虚拟交换机的预设容量2G，此时，UPF网元可以对两个终端设备各自的待传输数据进行丢包处理，并按照丢包后的结果进行数据传。而丢包的具体策略可以是随机丢包，可以是根据终端设备的优先级进行丢包，也即是实现了对不同终端设备的待传输数据的流量控制。

同时，UPF网元还可以确定终端设备3的待传输数据总量0.5G小于虚拟交换机的预设容量1G，则UPF网元可以直接将0.5G的待传输数据传输至终端设备3，无需进行丢包处理。

上述过程可以结合图4理解。

上述各实施例提供的虚拟交换机，可以同时为多个终端设备进行待传输数据的传输，此时，还可以设置虚拟交换机对不同终端设备的最大数据传输容量，也即是虚拟交换机对每个终端设备都可以设置一个预设容量。

则在为目标终端设备进行数据传输时，若目标终端设备的待传输数据的数据量小于此目标终端设备对应的预设容量，则虚拟交换机可以直接进行待传输数据的传输；否则，虚拟交换机可以对目标终端设备的待传输数据进行丢包处理，再将丢包处理后的剩余数据传输至目标终端设备，通过丢包处理能够对目标终端设备实现流量控制。

上述各实施例中重点描述了基于5G通信网络架构的虚拟交换机的工作过程。基于上述的虚拟交换机，图5为本发明实施例提供的一种数据传输系统的结构示意图。如图5所示，该系统包括：多个终端设备、虚拟交换机以及服务器。其中，虚拟交换机包括核心网中的SMF网元和UPF网元，并且多个终端设备可以位于同一群组内。

用户可以对自己使用的终端设备，即对多个终端设备中的目标终端设备触发会话建立操作，目标终端设备响应于此操作，可以生成第一会话建立请求。此会话建立请求会依次经过5G通信网络中的接入网、核心网中的AMF网元，最终被核心网中的SMF网元接收到。

SMF网元响应于目标终端设备产生的第一会话建立请求，确定虚拟交换机的预设容量，又可以根据第一会话建立请求中的设备标识确定目标终端设备的待传输数据，同时也可以建立目标终端设备与UPF网元之间的传输通道。可选地，虚拟交换机的预设容量可以预先写入SMF网元中，也可以借助NEF网元，直接写入UDM网元和/或PCF网元中，则SMF网元可以从UDM网元和/或PCF网元获取虚拟交换机的预设容量。

SMF响应于目标终端设备产生的第一会话建立请求，还会发送目标终端设备对应的第二会话建立请求中UPF网元。若UPF网元确定目标终端设备的待传输数据的数据量小于或等于预设容量，则UPF网元可以直接借助目标终端设备与UPF网元之间的传输通道进行数据传输。若UPF网元确定目标终端设备的待传输数据的数据量大于预设容量，则UPF网元会对目标终端设备的待传输数据进行丢包处理，再利用上述传输通道对丢包后剩余的待传输数据进行传输，也即是实现了对终端设备的待传输数据的流量控制。

在实际中，群组中的其他终端设备也可以产生第一会话建立请求，加上上述的目标终端设备，也即是群组中有多个终端设备都产生了第一会话建立请求。此时，与上述过程相同的，SMF网元可以根据第一会话建立请求中包含的设备标识，确定多个终端设备各自的待传输数据。同时，还可以生成个多个终端设备各自对应的第二会话建立请求，并将其发送至UPF网元。UPF网元在接收到多个第二会话建立请求后，进一步确定多个终端设备各自的待传输数据的数据总量。

若数据总量小于或等于虚拟交换机的预设容量，则UFP网元可以直接从服务器获取多个终端设备各自的待传输数据，并将其传输至相应的终端设备。若数据总量大于虚拟交换机的预设容量，则UFP网元对多个终端设备各自的待传输数据进行丢包处理，将丢包处理后的剩余待传输数据传输至相应的终端设备。

数据传输系统中的服务器可以存储有终端设备需要的待传输数据，承接图2所示的视频播放场景，本实施例中的服务器具体为存储有直播视频流的资源服务器；承接图3所示的自动驾驶场景，本实施例中的服务器用于接收车联网中路测设备采集路测数据，并根据此路测数据生成导航数据。

并且本实施例其他未详细描述的部分，可参考对图1至图3所示实施例的相关说明。该技术方案的执行过程和技术效果参见图1至图3所示实施例中的描述，在此不再赘述。

与上述实施例相同的，服务标识和预设容量之间可以存在对应关系。其中，服务标识与预设容量之间的对应关系可以预先写入SMF网元，也可以借助NEF网元，将对应关系写入UDM网元和/或PCF网元。则SMF网元可以直接获取此对应关系，或者从UDM网元和/或PCF网元中获取此对应关系。

此时，数据传输系统的工作过程可以描述为：

群组中的目标终端设备可以产生第一会话建立请求，SMF网元可以根据接收到的第一会话建立请求中包含的目标服务标识，确定与此目标服务标识对应的预设容量。同时，SMF网元还可以根据第一会话建立请求中包含的设备标识，确定目标终端设备的待传输数据。之后，SMF网元还可以向UPF网元发送目标终端设备对应的第二会话建立请求，以建立起SMF网元和UPF网元之间的传输通道，并通过此通道控制UPF网元从服务器获取目标终端设备的待传输数据，并进行数据传输。

在实际中，群组中的其他终端设备可以产生第一会话建立请求，加上上述的目标终端设备，也即是群组中有多个终端设备都产生了第一会话建立请求。此时，SMF网元可以根据多个终端设备产生的第一会话建立请求中包含的设备标识，确定每个终端设备的待传输数据。同时，SMF网元也可以生成个多个终端设备各自对应的第二会话建立请求，并将其发送至UPF网元。

UPF网元在接收到多个第二会话建立请求后，可以进一步确定多个终端设备各自产第一会话建立请求中包含的服务标识是否相同，从而确定多个终端设备各自的待传输数据的传输方式。

具体来说，若多个第一会话建立请求包含的服务标识完全相同，则UPF网元可以计算多个终端设备各自的待传输数据的数据总量。并根据数据总量和与服务标识对应的预设容量之间的大小关系，确定是直接传输多个终端设备的待传输数据，还是对多个终端设备的待传输数据进行流量控制。

若多个终端设备各自产生第一会话建立请求中包含的服务标识不完全相同，则SMF网元可以确定出多个预设容量。此时，UPF网元计算产生包含相同服务标识的第一会话建立请求的各终端设备的待传输数据的数据总量，同时也计算产生包含不同服务标识的第一会话建立请求的终端设备的待传输数据的数据量，并将计算结果分别与服务标识对应的预设容量进行比对，确定是否需要对待传输数据进行丢包处理。

并且本实施例其他未详细描述的部分，可参考对图4所示实施例的相关说明。该技术方案的执行过程和技术效果参见图4所示实施例中的描述，在此不再赘述。

需要说明的有，当终端设备的待传输数据具体为视频数据时，则图5所示的数据传输系统实际上就是视频数据传输系统。

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims (12)

1.一种虚拟交换机，其特征在于，包括：核心网中的会话管理功能网元和用户面功能网元；

所述会话管理功能网元，用于响应于目标终端设备产生的第一会话建立请求，确定所述虚拟交换机的预设数据转发容量；发送所述目标终端设备对应的第二会话建立请求至所述用户面功能网元；

所述用户面功能网元，用于响应于多个终端设备各自对应的第二会话建立请求，确定所述多个终端设备各自的待传输数据的数据总量，所述多个终端设备包含所述目标终端设备；根据所述数据总量和所述预设数据转发容量，确定所述多个终端设备各自的待传输数据的传输方式，以按照所述传输方式进行数据传输。

2.根据权利要求1所述的虚拟交换机，其特征在于，所述会话管理功能网元，用于获取预设数据转发容量与服务标识之间的对应关系，所述服务标识表明所述虚拟交换机通过数据传输使终端设备所能提供的服务；

根据所述第一会话建立请求中包含的目标服务标识，在所述对应关系中确定与所述目标服务标识对应的预设数据转发容量。

3.根据权利要求2所述的虚拟交换机，其特征在于，还包括：所述核心网中的统一数据管理功能网元和/或策略控制功能网元，用于存储预设数据转发容量与服务标识之间的对应关系。

4.根据权利要求3所述的虚拟交换机，其特征在于，还包括：所述核心网中的网络开放功能网元，用于响应于容量配置操作，借助所述网络开放功能网元提供的预设接口，将所述对应关系存储于所述统一数据管理功能网元和/或所述策略控制功能网元中。

5.根据权利要求2所述的虚拟交换机，其特征在于，所述用户面功能网元，用于若多个终端设备各自产生的第一会话建立请求中包含的服务标识相同，则响应于所述多个终端设备各自对应的第二会话建立请求，确定所述多个终端设备各自的待传输数据的数据总量。

6.根据权利要求1至5中任一项所述的虚拟交换机，其特征在于，所述用户面功能网元，用于若所述数据总量大于所述预设数据转发容量，则对所述多个终端设备中至少一个终端设备对应的待传输数据进行丢包处理。

7.根据权利要求1至5中任一项所述的虚拟交换机，其特征在于，所述用户面功能网元，还用于若所述数据总量小于或等于所述预设数据转发容量，则分别传输所述多个终端设备各自对应的待传输数据。

8.根据权利要求1所述的虚拟交换机，其特征在于，所述会话管理功能网元，用于根据所述会话管理功能网元提供的预设接口，发送所述目标终端设备对应的第二会话建立请求至所述用户面功能网元。

9.根据权利要求1所述的虚拟交换机，其特征在于，所述会话管理功能网元，用于根据多个终端设备各自产生的第一会话建立请求中包含的设备标识，确定所述多个终端设备各自的待传输数据。

10.一种虚拟交换机，其特征在于，包括：核心网中的会话管理功能网元和用户面功能网元；

所述会话管理功能网元，用于响应于目标终端设备产生的第一视频数据获取请求，确定所述虚拟交换机的预设数据转发容量；发送所述目标终端设备对应的第二视频数据获取请求至所述用户面功能网元；

所述用户面功能网元，用于响应于多个终端设备各自对应的第二视频数据获取请求，确定所述多个终端设备各自的待传输视频数据的数据总量，所述多个终端设备包含所述目标终端设备；根据所述数据总量和所述预设数据转发容量，确定所述多个终端设备各自的待传输视频数据的传输方式，以按照所述传输方式进行视频数据传输。

11.根据权利要求10所述的虚拟交换机，其特征在于，所述用户面功能网元，用于若所述数据总量大于所述预设数据转发容量，则对所述多个终端设备中至少一个终端设备对应的待传输视频数据进行丢包处理。

12.一种数据传输系统，其特征在于，包括：多个终端设备、虚拟交换机以及服务器；所述虚拟交换机包括核心网中的会话管理功能网元和用户面功能网元；

所述多个终端设备中的目标终端设备，用于响应于会话建立操作，生成第一会话建立请求；

所述会话管理功能网元，用于响应于所述第一会话建立请求，确定所述虚拟交换机的预设数据转发容量；发送所述目标终端设备对应的第二会话建立请求至所述用户面功能网元；

所述用户面功能网元，用于响应于所述多个终端设备各自对应的第二会话建立请求，确定所述多个终端设备各自的待传输数据的数据总量；从所述服务器获取所述多个终端设备各自的待传输数据；根据所述数据总量以及所述预设数据转发容量，确定所述多个终端设备各自的待传输数据的传输方式，以按照所述传输方式进行数据传输。

Images