一种铁路MCVideo系统组呼视频传输控制的方法与流程

一种铁路mcvideo系统组呼视频传输控制的方法
技术领域
1.本发明涉及铁路无线通信技术领域，尤其涉及一种铁路mcvideo系统组呼视频传输控制的方法。


背景技术：

2.随着铁路移动通信技术向宽带化、智能化的不断研究和推进，目前我国铁路已经明确将采用5g-r实现铁路下一代移动通信系统。
3.国际标准化组织3gpp（第三代合作伙伴计划）标准陆续推出了基于关键业务通信机制的系列标准：mcptt（关键语音通信）、mcdata（关键数据通信）和mcvideo（关键视频通信），以上三者统称为mcx（关键业务通信），它们成为未来集群通信的主要发展方向。mcx技术满足了铁路集群通信和调度通信业务的基本功能需求，已经成为国内外铁路集群和调度通信的解决方案，特别是mcvideo视频通信技术的提出，将极大地提升铁路通信的可视化、智能化水平。
4.公开号为cn109756851a的中国发明专利申请《一种基于mcvideo集群系统的话语权控制方法》中实现了基于mcvideo集群系统的话语权控制，并未详细介绍如何进行视频传输控制。授权公告号为cn109792565b中国发明专利《管理离网关键任务视频(mcvideo)通信系统中的mcvideo通信的方法》中介绍了离网情况下不需要mcvideo服务器支持，不同mcvideo终端设备之间直接视频通信的方式，并未介绍组呼时的视频传输控制方法。北京交通大学2020年的论文《宽带集群交换系统mcvideo视频传输功能的研究与实现》中介绍了mcvideo宽带集群交换系统中视频传输权控制的方式，但是，并未针对不同mcvideo终端用户的类别权限加以控制。此外，总体而言，以上方案都是基于3gpp标准。
5.但是，3gpp推出的mcvideo系统下组呼及视频传输控制等主要是面向公共安全网络，而铁路移动通信网络有其专用性和特殊性，与公共安全网络存在一定的差异；此外，铁路集群通信和调度通信业务应用场景具有特殊性，因此，不能适用3gpp标准中的mcvideo机制。


技术实现要素：

6.本发明的目的是提供一种铁路mcvideo系统组呼视频传输控制的方法，能够满足铁路集群通信和调度通信业务应用场景下对各类用户终端权限控制需求，有助于更合理运用铁路专网资源，且能够保证铁路视频组呼中视频传输的可行性、可控性和高效性。
7.本发明的目的是通过以下技术方案实现的：一种铁路mcvideo系统组呼视频传输控制的方法，包括：mcvideo服务器接收用户终端注册请求时，根据用户终端的类别为用户终端配置相应的权限；其中，所述mcvideo表示关键视频通信，视频组呼内发送视频的用户终端称为视频发送者，接收视频的用户终端称为视频接收者；当mcvideo服务器接收到视频发送者的发送视频请求时，对视频发送者以及发送
视频请求进行校验，校验通过后将携带有分配给视频发送者视频流的ssrc号的响应消息返回给视频发送者，并接收视频发送者发送的视频流；同时，将视频发送者的相关信息发送至视频发送者所在视频组呼内的其他用户终端；所述ssrc号表示同步信源号；当mcvideo服务器接收到视频接收者的接收指定视频发送者的视频请求时，结合视频接收者的权限进行校验，校验通过后将允许接收的响应消息返回给用户终端，并向视频接收者发送指定视频发送者的视频流。
8.由上述本发明提供的技术方案可以看出，可以根据用户终端特点和应用策略,对不同类别的用户终端分别配置不同的视频传输权限，在此基础上提出了一种更加完善的视频发送控制、传输通知、接收控制方法（统称为视频传输控制方法），通过用户视频传输权限配置与视频传输控制方法，极大地满足了铁路集群和调度通信应用要求，提高了指挥和沟通效率。
附图说明
9.为了更清楚地说明本发明实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他附图。
10.图1为本发明实施例提供的一种铁路mcvideo系统组呼视频传输控制的方法的流程图；图2为本发明实施例提供的用户终端视频传输权限配置流程图；图3为本发明实施例提供的视频发送控制处理流程图；图4为本发明实施例提供的视频发送通知处理流程图；图5为本发明实施例提供的视频停止发送通知处理流程图；图6为本发明实施例提供的视频接收控制处理流程图；图7为本发明实施例提供的功能号字段编码格式；图8为本发明实施例提供的用户接收多路视频处理策略的流程图；图9为本发明实施例提供的多mcvideo系统之间视频接收控制处理流程图；
具体实施方式
11.下面结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明的保护范围。
12.首先对本文中可能使用的术语进行如下说明：术语“包括”、“包含”、“含有”、“具有”或其它类似语义的描述，应被解释为非排它性的包括。例如：包括某技术特征要素（如原料、组分、成分、载体、剂型、材料、尺寸、零件、部件、机构、装置、步骤、工序、方法、反应条件、加工条件、参数、算法、信号、数据、产品或制品等），应被解释为不仅包括明确列出的某技术特征要素，还可以包括未明确列出的本领域公知的其它技术特征要素。
13.下面对本发明所提供的一种铁路mcvideo系统组呼视频传输控制的方法进行详细描述。本发明实施例中未作详细描述的内容属于本领域专业技术人员公知的现有技术。本发明实施例中未注明具体条件者，按照本领域常规条件或制造商建议的条件进行。本发明实施例中所用仪器未注明生产厂商者，均为可以通过市售购买获得的常规产品。
14.如图1所示，一种铁路mcvideo系统组呼视频传输控制的方法，主要包括如下步骤：步骤1、mcvideo服务器接收用户终端注册请求时，根据用户终端的类别为用户终端配置相应的权限。
15.本发明实施例中，根据用户终端的类别为用户终端配置相应的权限的优选实施方式如下：1）将用户终端分为三个类别：移动终端类型、有线固定终端类型与监测设备类型。
16.2）配置每一类别的用户终端可接收视频路数上限，将移动终端类型、有线固定终端类型与监测设备类型的上限依次设置为n1、n2与n3，满足：n2＞n1＞n3。
17.3）配置每一类别的用户终端之间互相查看视频的权限，包括：移动终端类型的用户终端具有查看除去有线固定终端类型的用户终端之外其他类别（包含其自身类别）用户终端视频的权限，有线固定终端类型的用户终端具有查看所有类别（包含其自身类别）用户终端视频的权限，监测设备类型的用户终端不具备查看任何类别用户终端视频的权限。
18.本发明实施例中，视频组呼内成员均为用户终端，根据用户终端发生的视频发送与视频接收动作为用户终端赋予不同的角色名称，例如，将视频组呼内发送视频的用户终端称为视频发送者，接收视频的用户终端称为视频接收者。视频发送者与视频接收者的角色是可以相互转换的，例如，上一时刻用户终端a发送视频，则其作为视频发送者；下一时刻用户终端a接收视频，则其作为视频接收者。
19.步骤2、当mcvideo服务器接收到视频发送者的发送视频请求时，对视频发送者以及发送视频请求进行校验，校验通过后将携带有分配给视频发送者的ssrc号的响应消息返回给视频发送者，并接收视频发送者发送的视频流；同时，将视频发送者的相关信息发送至视频发送者所在视频组呼内的其他用户终端；所述ssrc号表示同步信源号。
20.本发明实施例中，视频组呼建立完成之初，组呼发起者主动发送自身视频，其他组内成员主动接收发起者的视频，此时流程是自动完成无需用户终端干预。视频组呼建立流程如下：（1）某用户终端想要发起视频组呼，通过拨打组呼号码，发起视频组呼请求给mcvideo服务器，该用户终端即为组呼发起者；（2）mcvideo服务器收到视频组呼请求后，接通呼叫，并将组内其他成员逐一拉入组呼中，视频组呼建立完成。
21.视频组呼过程中，视频发送者在请求发送本地视频时，mcvideo服务器需对该视频发送者以及发送视频请求进行校验，判别是否允许相关请求；校验内容可以包括：视频发送者是否在视频组呼中，发送视频请求的格式是否正确，视频发送者是否有正在发送的视频。如果视频发送者在视频组呼中，发送视频请求的格式正确，且没有正在发送的视频，则通过校验，否则，未通过校验；通过校验后，允许视频发送者发送视频，并为视频发送者分配相应的ssrc号；如果未通过校验，则拒绝视频发送者发送视频；mcvideo服务器根据校验结果向视频发送者返回相应的相应消息，进而指示视频发送者发送或不发送视频流。并且，所述mcvideo服务器在接收视频发送者发送的视频流的过程中，若接收到该视频发送者发送的终止发送视频请求，则对该视频发送者以及终止发送视频请求进行校验，与之前类似的，校
验内容可以包括：视频发送者是否在视频组呼中，终止发送视频请求的格式是否正确，视频发送者是否有正在发送的视频。如果视频发送者在视频组呼中，终止发送视频请求的格式正确，且有正在发送的视频，则通过校验，否则，未通过校验。校验通过后将允许停止发送的响应消息返回给该视频发送者。
22.另外，所述mcvideo服务器接收到视频发送者发送的视频流后，还通过向各用户终端发送相关视频传输通知，实现告知视频组呼内其他用户终端当前视频发送方的状态变化。具体的：所述mcvideo服务器将视频发送者的相关信息（例如，用户终端的用户名、ssrc号与功能号等）发送至视频发送者所在视频组呼内的其他用户终端，由所述其他用户终端通过列表显示，进而可以根据需要选择所需接收的视频流；之后，当视频组呼内有新用户终端加入时，向所述新用户终端发送视频发送者的相关信息。当所述mcvideo服务器接收到视频发送者发送的终止发送视频请求，并允许视频发送者停止发送视频后，或者视频发送者退出视频组呼后，向视频组呼内的其他用户终端发送视频停止发送通知。
23.步骤3、当mcvideo服务器接收到视频接收者的接收指定视频发送者的视频请求时，结合视频接收者的权限进行校验，校验通过后将允许接收的响应消息返回给用户终端，并向视频接收者发送指定视频发送者的视频流。
24.如之前所述，通过视频传输通知视频组呼内的成员都可以了解视频组呼内各所具有的视频流信息，因此，可以根据需要接收指定视频发送者的视频流。同样的，mcvideo服务器接收到视频接收者的相关请求后需要结合视频接收者权限进行校验，此处的校验除了结合步骤1配置的权项进行校验（例如，校验视频接收者接收的视频路数是否达到上限，以及是否有查看指定视频发送者视频的权限）外，还需要对视频接收者的身份以及请求内容进行校验（例如，校验视频接收者是否为视频组呼成员，接收指定视频发送者的视频请求的格式是否正确等），如果满足前述步骤1配置的权限要求，属于视频组呼成员，且接收指定视频发送者的视频请求的格式正确，则通过校验，否则，未通过校验；根据校验结果向视频接收者反馈允许接收或不拒绝接收的响应消息。如果是允许接收，则将指定视频发送者的视频流发送给视频接收者。所述mcvideo服务器向视频接收者发送指定视频发送者的视频流的过程中，若接收到该视频接收者发送的终止接收视频请求，则对该视频接收者以及终止接收视频请求进行校验，例如，校验视频接收者是否为视频组呼成员，终止接收视频请求的格式是否正确，视频接收者当前是否有正在接收的视频；如果视频接收者为视频组呼成员，终止接收视频请求的格式正确，且当前有正在接收的视频，则通过校验，否则，未通过校验；校验通过后将允许停止接收的响应消息返回给该视频接收者。
25.为了便于理解，下面针对用户终端视频传输权限配置、视频发送控制、视频传输通知、视频接收控制四个部分做进一步的介绍。
26.1、用户终端视频传输权限配置。
27.mcvideo服务器根据用户特点和应用策略，构建视频组呼时对不同类别的用户终端分别分配不同的视频传输权限。如图2所示，主要包括：1）根据用户终端的特点和应用场景，在mcvideo服务器用户配置数据库中进行权限配置。根据铁路调度通信业务场景，将移动终端类型的用户终端设置为第一类用户，如车载台cir、手持台用户等；将有线固定终端类型的用户终端设置为第二类用户，如调度员和车站值班员等；将监测设备类型的用户终端设置为第三类用户，如摄像头等。
28.2）配置各类用户终端可接收视频路数上限。第一类用户可接收视频路数上限设为n1，第二类用户可接收视频路数上限设为n2，其他第三类用户可接收视频路数上限设为n3；示例性的，可以设置：n1=1，n2=4，n3=0。
29.3）配置各类用户终端相互之间查看视频的权限。示例性的，设置第一类用户可以查看除第二类用户之外其他用户的视频，第二类用户可以查看所有类型用户视频，第三类用户不能查看任何用户视频。
30.4）向用户终端下发视频传输权限配置。在终端注册登录服务器获取用户配置文件过程中，将上述视频传输权限下发给终端，作为视频传输控制的初始配置。权限配置由mcvideo服务器把控，发送给用户终端，仅用于告知用户终端，并且用户终端在后续请求的过程中可以在本地进行初步判别，但是最终的决定权在mcvideo服务器侧。
31.2、视频发送控制。
32.各用户终端和mcvideo服务器之间通过视频发送控制消息，实现各用户终端将本地视频上传至mcvideo服务器的过程，当然，此阶段，发送视频的用户终端作为视频发送者，考虑到视频发送者与视频接收者这样名称主要是为了在区分不同用户终端的角色，但此阶段只涉及视频发送者这一种角色，因此，此部分的介绍依然使用用户终端这一名称。如图3所示，主要包括：1）用户终端向mcvideo服务器发出发送视频请求，并携带自身的用户名和功能号（如有）。
33.2）mcvideo服务器收到发送视频请求，校验相关权限（即校验视频发送者是否在视频组呼中，发送视频请求的格式是否正确，视频发送者是否有正在发送的视频），若校验通过允许后，向用户终端发送允许发送视频响应，并携带分配给该用户终端发送视频流时对应的ssrc号；若校验未通过，则向该用户终端发送拒绝发送响应。
34.3）用户终端收到允许发送响应后，开始发送本地视频到mcvideo服务器；收到拒绝发送响应后，则不能发送。
35.4）若已经在发送视频的用户终端要终止发送视频，则需要向mcvideo发送停止发送视频请求，并携带请求者的用户名和功能号（如有）。
36.5）mcvideo服务器收到停止发送视频请求，校验相关权限（即校验视频发送者是否在视频组呼中，终止发送视频请求的格式是否正确，视频发送者是否有正在发送的视频），若校验通过允许后，向该用户终端发送允许停止响应。
37.6）用户终端收到允许停止响应后，终止视频发送。
38.3、视频传输通知。
39.mcvideo服务器通过向各用户终端发送相关视频传输通知，实现告知组内其他用户当前视频发送方的状态变化。
40.1）当mcvideo服务器允许某视频发送者发送视频后，需要向组内其他用户终端发送视频发送通知，告知当前可选视频发送者的信息，包括用户名、媒体流ssrc号和功能号（如有）。其他用户终端收到该通知后，在相关列表进行显示，用于后续接收该用户视频。
41.2）组呼已建立，当有新的用户终端后加入时，mcvideo服务器需要主动向该新的用户终端发送视频发送通知，告知当前可选视频发送者的信息，包括用户名、ssrc号和功能号（如有）。
42.3）当mcvideo服务器允许某视频发送者停止发送视频后，需要向组内其他用户终端发送视频停止发送通知，告知当前哪些视频发送者已停止的信息，包括用户名、ssrc号和功能号（如有）。
43.4）当某正在发送视频的视频发送者挂断退出组呼后，mcvideo服务器需要向组内其他用户终端发送视频停止发送通知，告知当前哪些视频发送者已停止的信息，包括用户名、ssrc号和功能号（如有）。
44.如图4所示，为视频发送通知处理流程图。如图5所示，为视频停止发送通知处理流程图。
45.4、视频接收控制。
46.各用户终端和mcvideo服务器之间通过视频接收控制，实现各用户从mcvideo服务器接收其他用户视频的过程。如图6所示，主要包括：1）用户终端（视频接收者）向mcvideo服务器发送接收指定视频发送者的视频请求，携带视频接收者的用户名和视频发送者的ssrc号。
47.2）mcvideo服务器收到请求后，校验相关权限，若校验通过允许后，向视频接收者发送允许接收响应，然后开始向该视频接收者转发视频流；若校验未通过，则向该视频接收者发送拒绝接收响应。
48.3）视频接收者收到允许接收响应后，开始视频接收。
49.4）若已经在接收视频的视频接收者要终止接收视频，或收到指定视频发送者已停止发送的通知，则该视频接收者需要向mcvideo发送停止接收视频请求，并携带指定视频发送者的ssrc号。
50.5）mcvideo服务器收到停止接收视频请求，校验相关权限，若校验通过允许后，向该视频接收者发送允许停止接收响应，并停止向该视频接收者转发指定视频流。
51.6）视频接收者收到允许停止接收响应后，终止视频接收。
52.在上述视频传输控制方法的基础上，本发明还提出了视频传输控制过程的功能号传递方法，用户终端接收多路视频处理策略，以及多mcvideo系统视频传输控制方式。
53.1、视频传输控制过程的功能号传递方法。
54.功能号（functional number，fn）是根据用户终端工作岗位的功能或角色所定义的号码，是铁路调度通信业务中重要的用户身份标识。在标准的3gpp mcvideo视频传输控制中，并没有涵盖功能号信息，针对铁路调度通信具体应用需求，在视频传输控制信息中加入功能号信息，有助于各用户准确的掌握视频流具体角色来源，将极大地提高指挥沟通效率，因此，在上述视频传输控制的方法中，会均携带有相应视频发送者对应的用户终端的功能号，具体为，前述视频发送控制中的第1）、4）部分，视频传输通知中的第1）~4）部分。
55.图7展示了功能号字段编码格式，主要包括：功能号字段id部分（fn field id）、功能号长度部分（fn length）与功能号内容部分（fn）。
56.1）功能号字段id部分用于标识功能号字段名，一般为一个二进制值；示例性的，与标准3gpp mcvideo视频传输控制已定义的特定字段id进行区分，功能号字段id部分的十进制值为021，二进制值为00010101。
57.2）功能号长度部分用于标识功能号内容部分的长度，一般为一个二进制值，标识《fn》的长度，但不包括空白填充补位字段的长度。
58.3）功能号内容部分包含功能号的具体内容，一般为功能号对应的字符串。
59.通常来说，如果功能号内容部分的长度不是（2 4的倍数）字节，填充（padding）为（2 4的倍数）字节，填充字节的值为0，填充字节被接收方忽略。
60.本发明实施例中，所述用户终端的功能号的数目为一个或多个，当数目为多个时，仅携带优先级最高的功能号；优先级大小顺序为：车次功能号》机车功能号》车号功能号》其它功能号；其中，所述其它功能号表示除去车次功能号、机车功能号与车号功能号之外的其他类别的功能号。
61.2、用户终端接收多路视频处理策略。
62.在视频组呼中，用户终端（视频接收者）可以接收多路来自其他用户终端（视频发送者）的视频，而且各个用户终端接收的视频用户并不统一，且在视频组呼过程中，各用户终端选看的视频可能存在变化，即呈现为各用户终端具体接收选看哪些视频由用户终端自身决定。因此，如果由mcvideo服务器实现对各个用户终端请求的多路视频合成一路视频的处理工作，由于各个用户终端的视频合成策略不一，容易引起mcvideo服务器的视频处理负载较高的问题，且很可能对视频传输实时性影响较大。
63.本发明实施例中，提出由各用户终端实现多路视频显示工作，即mcvideo服务器维护视频传输控制决策，并根据策略转发给各用户终端对应的视频流，由各用户终端完成自身接收的多路视频处理工作。其中，关键点为mcvideo服务器统一控制和分配各用户终端视频流的ssrc号，各用户终端通过ssrc请求和区分其他用户的视频流。
64.如图8所示，展示了用户终端接收多路视频处理策略的原理，由mcvideo服务器为不同视频发送者分配不同的ssrc号，视频接收者根据ssrc号区分不同视频发送者，接收来自不同视频发送者的视频流后，依据ssrc号区分不同视频流的来源。
65.3、多mcvideo系统视频传输控制方式。
66.本发明实施例中，当视频组呼内的用户终端属于多个mcvideo系统时，将视频组呼归属的mcvideo系统作为主控系统，其他mcvideo系统作为参与系统；由主控系统中的mcvideo服务器负责接收来自视频发送者与视频发送者的请求，以及负责权限校验后反馈相应的响应消息；所述主控系统中的视频发送者与视频发送者直接与主控系统中的mcvideo服务器进行通信，参与系统中的视频发送者与视频发送者通过所属mcvideo系统中的mcvideo服务器与主控系统中的mcvideo服务器进行通信。图9展示了多mcvideo系统视频传输控制方式的原理。
67.本发明实施例中，视频组呼归属的mcvideo系统是指用于管理视频组呼的mcvideo系统，在视频组呼建立过程中，也是由该mcvideo系统的mcvideo服务器负责将各成员（用户终端）拉入视频组呼中，并保存有视频组呼的所有信息配置，包括组信息和各成员信息等。
68.通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例可以通过软件实现，也可以借助软件加必要的通用硬件平台的方式来实现。基于这样的理解，上述实施例的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质（可以是cd-rom，u盘，移动硬盘等）中，包括若干指令用以使得一台计算机设备（可以是个人计算机，服务器，或者网络设备等）执行本发明各个实施例所述的方法。
69.以上所述，仅为本发明较佳的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明披露的技术范围内，可轻易想到的变化或替换，
都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应该以权利要求书的保护范围为准。