CN110177344B - 一种组附着方法、客户端和服务器端 - Google Patents

Abstract

本申请公开了一种组附着方法、客户端和服务器端，该方法包括：确认客户端所需的组呼业务类型；发送携带组呼业务类型的组附着请求至服务器端，其中，组呼业务类型用于指示客户端加入对应的组呼活动后所能够传输的媒体类型和/或媒体上下行传输方向；接收服务器发送的组附着响应消息。通过上述方式，本申请能够在组附着时设置客户端所需的组呼业务类型，实现为客户端合理分配资源。

Description

一种组附着方法、客户端和服务器端

技术领域

本申请涉及通信技术领域，具体涉及一种组附着方法、客户端和服务器端。

背景技术

关键任务一键通(MCPTT，Mission Critical Push To Talk)是第三代合作伙伴计划(3GPP，Third Generation Partnership Project)为了解决公共安全，在长期演进(LTE，Long Term Evolution)之上建立的一整套集群通信系统，可以实现对公共安全通信领域语音通信的支持。

本申请的发明人在长期研发中发现，MCPTT系统中如果用户加入某个群组，需要发送附着(Affiliate)请求，才可以参与这个群组的呼叫活动，否则就不能参加这个组的任何活动；但是Affiliate请求消息单一不灵活，不能设置加入组呼的条件，如仅需要上传权限、下载权限以及上传和下载权限都需要等。

发明内容

本申请主要解决的问题是提供一种组附着方法、客户端和服务器端，能够在加入组呼时设置客户端所需的组呼业务类型，实现为客户端合理分配资源。

为解决上述技术问题，本申请采用的技术方案是提供一种组附着方法，该方法包括：确认客户端所需的组呼业务类型；发送携带组呼业务类型的组附着请求至服务器端，其中，组呼业务类型用于指示客户端加入对应的组呼活动后所能够传输的媒体类型和/或媒体上下行传输方向；接收服务器发送的组附着响应消息。

为解决上述技术问题，本申请采用的另一技术方案是提供一种组附着方法，该方法包括：接收客户端发送的携带组呼业务类型的组附着请求；根据组呼业务类型对客户端加入对应的组呼活动后所能够使用的资源进行配置。

为解决上述技术问题，本申请采用的另一技术方案是提供一种客户端，该客户端包括：处理器和通信电路，处理器用于确认客户端所需的组呼业务类型，生成携带组呼业务类型的组附着请求；通信电路用于将组附着请求发送至服务器端，以指示服务器端根据组呼业务类型对客户端加入对应的组呼活动后所能够使用的资源进行配置。

为解决上述技术问题，本申请采用的另一技术方案是提供一种服务器端，该服务器端包括：通信电路和处理器，通信电路用于接收客户端发送的组附着请求；处理器用于从组附着请求中获取组呼业务类型，并根据组呼业务类型对客户端加入对应的组呼活动后所能够使用的资源进行配置。

通过上述方案，本申请的有益效果是：确认客户端所需的组呼业务类型；然后将组呼业务类型添加到组附着请求中，并将组附着请求发送给服务器端；服务器端将客户端加入组呼活动中，并根据组呼业务类型对客户端能够使用的资源进行配置，从而可以使得在加入组呼时设置客户端所需的组呼业务类型，实现为客户端合理分配资源。

附图说明

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

图1是现有技术中的组附着流程示意图；

图2是本申请提供的组附着方法第一实施例的流程示意图；

图3是本申请提供的组附着方法第二实施例的流程示意图；

图4是本申请提供的组附着方法第三实施例的流程示意图；

图5是本申请提供的组附着方法第四实施例的流程示意图；

图6是本申请提供的组附着方法第五实施例的流程示意图；

图7是本申请提供的组附着方法第六实施例中客户端和服务器端交互的流程示意图；

图8是本申请提供的组附着方法第六实施例中客户端和服务器端交互的另一的流程示意图；

图9是本申请提供的客户端一实施例的结构示意图；

图10是本申请提供的服务器端一实施例的结构示意图。

具体实施方式

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

现有技术中客户端申请组附着的流程如图1所示，客户端向服务器请求加入服务组；服务器检查本地是否缓存组策略，如果组策略未在服务器上本地缓存，则服务器向组管理服务器请求组策略；服务器从组管理服务器接收组策略；基于组策略和用户订阅，服务器检查服务组是否已启用以及客户端是否被授权加入所请求的服务组，服务器还检查服务组的总数的最大限制；如果客户端被授权加入所请求的服务组，则服务器存储客户端对所请求的服务组的加入状态；服务器向客户端确认从属关系，并用所请求的服务组的用户的关联状态更新组管理服务器。

由此可见，在现有技术中，无法对客户端加入组呼的条件进行配置，无法适用于用户的多种组呼需求，例如：用户仅想获取上传权限或下载权限。

参阅图2，图2是本申请提供的组附着方法第一实施例的流程示意图，该方法包括：

步骤21：确认客户端所需的组呼业务类型。

在一具体实施方式中，可根据用户在客户端的输入界面的操作获取所需的组呼业务类型，例如：在客户端的输入界面设置分别对应于不同组呼业务模式的特定按键，根据用户对不同按键的操作来获取相应的组呼业务类型。

在另一具体实施方式中，可以根据客户端的工作状态获取所需的组呼业务类型，例如：根据客户端处于正常工作模式还是省电工作获取不同的组呼业务类型。

另外，客户端可以预设有默认组呼业务类型和候选组呼业务类型，当用户进行特定操作或客户端处于特定状态时，直接将默认组呼业务类型作为客户端所需的组呼业务类型，而在用户进行其他操作或客户端处于其他状态时，选择相应的候选组呼业务类型作为客户端所需的组呼业务类型。

步骤22：发送携带组呼业务类型的组附着请求至服务器端。

在确认组呼业务类型之后，客户端将组呼业务类型添加到组附着请求中，客户端为了加入组呼活动中，将发送一个携带组呼业务类型的组附着请求给服务器，该组呼业务类型用于指示客户端加入对应的组呼活动后所能够传输的媒体类型和/或媒体上下行传输方向。

客户端将组附着请求发送给服务器端，服务器端将客户端加入组呼活动中，并根据接收的组附着请求对客户端加入组呼活动后能够使用的资源进行配置，使得客户端可以获得相应的资源。

步骤23：接收服务器发送的组附着响应消息。

在服务器端为客户端分配资源的同时，服务器端发送组附着响应消息给客户端，以通知服务器端已经同意客户端的组附着请求，并为其分配了与组呼业务类型对应的资源。

区别于现有技术，本实施例提供了一种组附着方法，确认客户端所需的组呼业务类型；然后将组呼业务类型添加到组附着请求中，并将组附着请求发送给服务器端；服务器端将客户端加入组呼活动中，并根据组呼业务类型对客户端能够使用的资源进行配置，从而可以使得在加入组呼时设置客户端所需的组呼业务类型，实现为客户端合理分配资源。

参阅图3，图3是本申请提供的组附着方法第二实施例的流程示意图，该方法包括：

步骤31：确认客户端所需的组呼业务类型。

步骤32：发送携带组呼业务类型的组附着请求至服务器端。

步骤33：接收服务器发送的组附着响应消息。

其中，步骤31-33与第一实施例中步骤11-13相同，在此不再赘述。

步骤34：将客户端的输入界面上与组呼业务类型无关的按键进行隐藏或禁用。

为了使得客户端的输入界面简洁或方便用户操作，可以将客户端的输入界面上与组呼业务类型无关的按键进行隐藏或禁用。

可以理解地，在组呼通话中，客户端可以发送更改的组附着请求，以更改组呼业务类型，使得服务器端为客户端重新分配相应的资源。

在一具体实施方式中，组呼业务类型为第一业务类型、第二业务类型和第三业务类型中的任意一个；第一业务类型指示客户端需要上传和下载媒体，该媒体可以为语音数据或视频数据等；第二业务类型指示客户端仅需要下载媒体；第三业务类型指示客户端仅需要上传媒体。

区别于现有技术，本实施例提供了一种组附着方法，利用客户端发送携带组呼业务类型的组附着请求发送给服务器端；服务器端将客户端加入组呼活动中，并为客户端配置资源；然后获取服务器端的组附着响应，并隐藏或禁用客户端的输入界面上与组呼业务类型无关的按键，从而可以使得在加入组呼时设置客户端所需的组呼业务类型，实现为客户端合理分配资源，简化客户端的输入界面。

参阅图4，图4是本申请提供的组附着方法第三实施例的流程示意图，该方法包括：

步骤41：接收客户端发送的携带组呼业务类型的组附着请求。

为了将客户端加入组呼，服务器端需要获取客户端发送的组附着请求，该组附着请求包括组呼业务类型，服务器端可以为MCPTT服务器；在服务器端获取到组附着请求之后，服务器从该组附着请求中提取组呼业务类型，用以为客户端分配与组呼业务类型相匹配的资源，服务器将客户端加入组呼活动中。

步骤42：根据组呼业务类型对客户端加入对应的组呼活动后所能够使用的资源进行配置。

服务器在获取组呼业务类型之后，根据组呼业务类型对客户端加入对应的组呼活动后所能够使用的资源进行配置，使得客户端可以获得相应的资源。

进一地，客户端将组附着请求发送至服务器端，服务器端根据组呼业务类型对客户端在加入组呼活动后能够传输的媒体类型和/或媒体方向进行配置。

区别于现有技术，本实施例提供了一种组附着方法，利用服务器端获取组附着请求中包含的组呼业务类型；然后将客户端加入组呼活动中，并根据组呼业务类型对客户端能够使用的资源进行配置，从而可以使得在加入组呼时设置客户端所需的组呼业务类型，实现为客户端合理分配资源。

参阅图5，图5是本申请提供的组附着方法第四实施例的流程示意图，该方法包括：

步骤51：接收客户端发送的携带组呼业务类型的组附着请求。

其中，步骤51与第三实施例中步骤41相同，在此不再赘述。

步骤52：判断组呼活动是否已建立。

步骤53：若未建立，则建立与组呼业务类型相关的承载。

步骤54：若已建立，则释放与组呼业务类型无关的承载。

检测组呼活动是否已经建立，如果组呼活动未建立，则服务器端建立与获取到的组呼业务类型相关的承载；如果组呼活动已经建立，则服务器端释放与获取到的组呼业务类型无关的承载。

例如，服务器端为MCPTT应用服务器，组呼业务类型为下行承载，如果组呼活动未建立，则MCPTT应用服务器只分配下行承载给MCPTT客户端，不分配上行承载给MCPTT客户端；如果组呼活动已建立，则MCPTT应用服务器释放上行承载。

区别于现有技术，本实施例提供了一种组附着方法，利用服务器端获取组附着请求中包含的组呼业务类型；服务器端根据组呼活动是否建立为客户端分配相应的承载，从而可以使得在加入组呼时设置客户端所需的组呼业务类型，合理分配资源。

参阅图6，图6是本申请提供的组附着方法第五实施例的流程示意图，该方法包括：

步骤61：接收客户端发送的携带组呼业务类型的组附着请求。

其中，步骤61与第三实施例中步骤41相同，在此不再赘述。

步骤62：当组呼业务类型为第一业务类型时，为客户端同时分配上行承载和下行承载，以允许客户端上传和下载媒体。

如果服务器检测到获取到的组呼业务类型为第一业务类型，则服务器端为客户端分配上行承载和下行承载，使得客户端能够进行上传和下载媒体数据，即客户端的所属用户能够发送和接收语音或视频信息。

步骤63：当组呼业务类型为第二业务类型时，仅为客户端分配下行承载，以允许客户端下载媒体。

如果服务器检测到获取到的组呼业务类型为第二业务类型，则服务器端为客户端分配下行承载，客户端能够进行下载媒体数据，即客户端的所属用户仅仅能够接收语音或视频信息。

步骤64：当组呼业务类型为第三业务类型时，仅为客户端分配上行承载，以允许客户端上传媒体。

如果服务器检测到获取到的组呼业务类型为第三业务类型，则服务器端为客户端分配上行承载，客户端能够进行上传媒体数据，即客户端的所属用户能够发送语音或视频信息。

区别于现有技术，本实施例提供了一种组附着方法，利用服务器端获取组附着请求中包含的组呼业务类型；然后服务器端根据组呼业务类型所属类别为客户端分配相应的承载，从而可以使得在加入组呼时设置客户端所需的组呼业务类型，合理分配资源。

参阅图7，图7是本申请提供的组附着方法第六实施例中客户端和服务器端交互的流程示意图，该方法包括：

步骤71：客户端发送组附着请求给服务端。

组呼业务类型包括第一业务类型(即上行业务和下行业务)、第二业务类型(即下行业务)和第三业务类型(即上行业务)。

客户端初始发送的组呼业务类型为上行业务和下行业务(即第一业务类型)。此时，服务器端为客户端同时分配上行承载和下行承载。客户端加入组呼后，具有发送媒体和接收媒体的权限。

步骤72：服务器端根据接收到的组附着请求发送组附着响应给客户端。

服务器端在接收到客户端发送的组附着请求之后，根据组附着请求发送一组附着响应给客户端，用以通知服务器端同意客户端加入组呼中。

步骤73：客户端发送更改的组附着请求给服务端。

随后，当用户想要只接听组呼时，可通过对客户端进行操作，客户端发送更改的组附着请求给服务器端，该更改后的组附着请求中将组呼业务类型设置为下行业务(即第二业务类型)。

步骤74：服务器端根据接收到的组附着请求发送组附着响应给客户端。

服务器端在接收到更改后的组附着请求之后释放上传承载，并发送组附着响应给客户端；此时，客户仅具有接收媒体的权限。

可以理解地，本实施例中客户端和服务器端交互的过程并不仅限于图7中所示，还可以在发送初始的组附着请求时，将组呼业务类型设置为其他业务类型，以满足用户的需要。

例如，如图8所示，客户端发送的组附着请求中组呼业务类型为第二业务类型，服务器端在接收到客户端发送的组附着请求后，返回一个组附着响应给客户端，用以通知客户端成功附着到组中，服务器端不会建立上行承载，仅为客户端分配下行承载，允许客户端接收语音或视频信息，客户端的输入界面可以隐藏或禁用话权按钮，以简化客户端的输入界面或方便用户操作。

此外，可以设置当用户按下客户端上的预设按键(如“*”键或“#”键)时，客户端向服务器端发送更改的组附着请求，该更改的组附着请求包括更改组呼业务类型为客户端所需的业务类型；在组呼通话过程中组呼群组中的任一用户就可以通过在各自终端上按预设的按键，实现向服务器端申请更改业务类型为上行业务、下行业务和既有上行业务又有下行业务的三种类型中的至少一个。

例如，客户端2的所属用户在组呼过程中已经没有需要上传的媒体数据，为了节约承载资源，则可以通过按客户端2中输入界面上的“#”键，发送更改的组附着请求到服务器端，服务器端经分析得到该更改的组附着请求为用户B发送的将组呼业务类型更改为下行业务的消息，则可以释放客户端的上行承载资源，节约了承载资源。

区别于现有技术，本实施例提供了一种组附着方法，利用客户端发送携带组呼业务类型的组附着请求给服务器端，使得服务器端为客户端分配合适的资源，可以使得在加入组呼时设置客户端所需的组呼业务类型，实现为客户端合理分配资源，并可以在组呼活动的过程中利用客户端发送更改的组附着请求给服务器端，能够实时分配资源，提高用户体验。

参阅图9，图9是本申请提供的客户端一实施例的结构示意图，该客户端90包括：处理器91和通信电路92。

处理器91用于确认客户端90所需的组呼业务类型，生成携带组呼业务类型的组附着请求；通信电路92与处理器91连接，通信电路92用于将组附着请求发送至服务器端(图中未示出)，以指示服务器端根据组呼业务类型对客户端加入对应的组呼活动后所能够使用的资源进行配置；客户端90可以为摄像头，业务需求为仅上传媒体数据。

参阅图10，图10是本申请提供的服务器端一实施例的结构示意图，该服务器端100包括：互相连接的通信电路101和处理器102。

通信电路101用于接收客户端发送的组附着请求；处理器102用于从组附着请求中获取组呼业务类型，并根据组呼业务类型对客户端加入对应的组呼活动后所能够使用的资源进行配置。

在本申请所提供的几个实施方式中，应该理解到，所揭露的方法以及设备，可以通过其它的方式实现。例如，以上所描述的设备实施方式仅仅是示意性的，例如，模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。

作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施方式方案的目的。

另外，在本申请各个实施方式中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

以上仅为本申请的实施例，并非因此限制本申请的专利范围，凡是利用本申请说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本申请的专利保护范围内。

Claims (8)

1.一种组附着的实现方法，其特征在于，所述方法包括：

确认客户端所需的组呼业务类型；

发送携带所述组呼业务类型的组附着请求至服务器端；

其中，所述组呼业务类型用于指示所述客户端加入对应的组呼活动后所能够传输的媒体类型和/或媒体上下行传输方向；

接收所述服务器发送的组附着响应消息。

2.根据权利要求1所述的方法，其特征在于，所述组呼业务类型为第一业务类型、第二业务类型和第三业务类型中的任意一个；

其中，所述第一业务类型指示所述客户端需要上传和下载媒体；

所述第二业务类型指示所述客户端仅需要下载媒体；

所述第三业务类型指示所述客户端仅需要上传媒体。

3.根据权利要求1所述的方法，其特征在于，在接收服务器发送的组附着响应消息的步骤后，还包括：

将所述客户端的输入界面上与所述组呼业务类型无关的按键进行隐藏或禁用。

4.一种组附着方法，其特征在于，所述方法包括：

接收客户端发送的携带组呼业务类型的组附着请求；

根据所述组呼业务类型对所述客户端加入对应的组呼活动后所能够传输的媒体类型和/或媒体方向进行配置。

5.根据权利要求4所述的方法，其特征在于，所述根据所述组呼业务类型对所述客户端加入对应的组呼活动后所能够传输的媒体类型和/或媒体方向进行配置的步骤包括：

判断所述组呼活动是否已建立；

若未建立，则建立与所述组呼业务类型相关的承载；

若已建立，则释放与所述组呼业务类型无关的承载。

6.根据权利要求4所述的方法，其特征在于，所述根据所述组呼业务类型对所述客户端加入对应的组呼活动后所能够传输的媒体类型和/或媒体方向进行配置的步骤包括：

当所述组呼业务类型为第一业务类型时，为所述客户端同时分配上行承载和下行承载，以允许所述客户端上传和下载媒体；

当所述组呼业务类型为第二业务类型时，仅为所述客户端分配下行承载，以允许所述客户端下载媒体；

当所述组呼业务类型为第三业务类型时，仅为所述客户端分配上行承载，以允许所述客户端上传媒体。

7.一种客户端，其特征在于，所述客户端包括：

处理器用于确认客户端所需的组呼业务类型，生成携带所述组呼业务类型的组附着请求；

通信电路，用于将组附着请求发送至服务器端，以指示所述服务器端根据所述组呼业务类型对所述客户端加入对应的组呼活动后所能够传输的媒体类型和/或媒体方向进行配置。

8.一种服务器端，其特征在于，所述服务器端包括：

通信电路，用于接收客户端发送的组附着请求；

处理器，用于从所述组附着请求中获取组呼业务类型，并根据所述组呼业务类型对所述客户端加入对应的组呼活动后所能够传输的媒体类型和/或媒体方向进行配置。

Images