CN102271320A

CN102271320A - 业务协商方法及系统

Info

Publication number: CN102271320A
Application number: CN2010101977970A
Authority: CN
Inventors: 刘海军
Original assignee: ZTE Corp
Current assignee: Changsha Yongnuo Technology Co.,Ltd.; Juxian Stone Association
Priority date: 2010-06-03
Filing date: 2010-06-03
Publication date: 2011-12-07
Anticipated expiration: 2030-06-03
Also published as: CN102271320B

Abstract

本发明公开了一种业务协商方法及系统，上述方法包括：第一设备接收来自第二设备的业务协商请求消息，其中，业务协商请求消息用于指示第二设备接受和/或不接受的业务，以及接受的业务中接受和/或不接受的功能；第一设备向第二设备发送业务协商响应消息，其中，协商响应消息用于指示第一设备向第二设备提供和/或不提供的业务，以及提供的业务中提供和/或不提供的功能。本发明提供的技术方案，设备之间进行业务级别、以及具体业务内功能的偏好协商，使得用户期望的业务或者业务功能特征在业务执行之前或执行过程中，可以被实时地协商，不受具体业务特点的限制，对业务及业务功能的偏好性协商具有通用性强，兼容性好，通讯效率高的优点。

Description

业务协商方法及系统

技术领域

本发明涉及通信领域，具体而言，涉及一种业务协商方法及系统。

背景技术

随着移动终端技术的成熟，终端已经能够满足基本的能力或能力集以实现通信网路的各种业务，移动通信新业务的设计开发，对电信终端的要求也尽可能地小，一般避免增加新的需要终端处理的信令消息，避免增加新的需要终端处理的媒体数据，充分考虑使用绝大多数终端都支持的功能，包括已有的信令、媒体、操作功能等。

在实际应用中存在这样一类业务，即由B用户订制，给A用户使用的业务，一般情形无论A用户是否愿意接受该业务，往往必须被动地体验该业务。这类业务中的一个典型例子是彩铃业务。

相关技术中，为满足A用户的意愿，一种方法是：针对用户A偏好的基本功能(基本能力)，在用户A的请求中设置能力级别的偏好命令或参数来传递A用户的请求。业务服务器保存用户A的功能偏好，并依据用户A的功能偏好，对涉及到相关功能的任何具体业务进行剪裁，保留用户喜欢的功能，屏蔽用户不愿接收的功能。这种方法可能会带来如下问题：例如，用户A只是不喜欢业务1中的语音功能，但是喜欢业务2中的语音功能，用户A通过上述方法通知业务服务器其不喜欢语音功能，导致业务服务器将业务1和业务2中的语音服务都剪裁掉。另一种方法是：在建立某种业务连接时，在用户A的请求中设置针对该业务的能力级别的偏好设置。导致每种业务的请求消息中都必须携带能力级别的偏好设置信息，使得消息体越来越庞大，影响到通讯效率。

发明人发现，无论采用上述哪种相关技术，均只能进行能力级别的偏好设置，不能实现业务级别的协商，对于所有种类的业务来说，存在偏好设置通用性不强，兼容性差，通讯效率低的问题。

发明内容

本发明的主要目的在于提供一种业务协商方法及系统，以解决上述问题。

根据本发明的一个方面，提供了一种业务协商方法，包括：第一设备接收来自第二设备的业务协商请求消息，其中，业务协商请求消息用于指示第二设备接受和/或不接受的业务，以及接受的业务中接受和/或不接受的功能；第一设备向第二设备发送业务协商响应消息，其中，协商响应消息用于指示第一设备向第二设备提供和/或不提供的业务，以及提供的业务中提供和/或不提供的功能。

根据本发明的另一方面，提供一种业务协商系统，包括：第二设备，用于向第一设备发送业务协商请求消息，其中，业务协商请求消息用于指示第二设备接受和/或不接受的业务，以及接受的业务中接受和/或不接受的功能；第一设备，用于接收来自第二设备的业务协商请求消息，并且向第二设备发送业务协商响应消息，其中，协商响应消息用于指示第一设备向第二设备提供和/或不提供的业务，以及提供的业务中提供和/或不提供的功能。

通过本发明，设备之间进行业务级别的偏好协商，以及具体业务内功能的偏好协商，使得用户期望的业务或者业务功能特征在业务执行之前或执行过程中，可以被实时地协商，不受具体业务特点的限制，对业务及业务功能的偏好性协商具有通用性强，兼容性好，通讯效率高的优点。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是根据本发明实施例一的业务协商系统框图；

图2是根据本发明实施例二的业务协商方法流程图；

图3是根据本发明实施例三的业务协商处理流程示意图。

具体实施方式

下文中将参考附图并结合实施例来详细说明本发明。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

实施例一

在本实施例中，提供了一种业务协商系统，如图1所示，该系统包括：第一设备10和第二设备20，其中，

第二设备20，用于向第一设备10发送业务协商请求消息，其中，所述业务协商请求消息用于指示所述第二设备20接受和/或不接受的业务，以及所述接受的业务中接受和/或不接受的功能；

第一设备10，用于接收来自所述第二设备20的业务协商请求消息，并且向所述第二设备20发送业务协商响应消息，其中，所述协商响应消息用于指示所述第一设备10向所述第二设备20提供和/或不提供的业务，以及所述提供的业务中提供和/或不提供的功能。

针对业务或业务能力的偏好设置，现有的系统中，设备只能进行业务能力级别的偏好设置，不能实现业务级别的协商，对于所有种类的业务来说，存在偏好设置通用性不强，兼容性差，通讯效率低等问题。本实施例提供的上述系统，通过设备10和设备20之间进行业务级别的偏好协商，以及具体业务内功能的偏好协商，使得用户期望的业务或者业务功能特征在业务执行之前或执行过程中，可以被实时地协商，不受具体业务特点的限制，例如，多业务并存的情况下，不会屏蔽掉所有业务中的同一个业务功能。再如，某个业务升级后，服务器端增加了新的功能，由于终端用户在业务协商请求消息中指示了能够接受或不能接受的业务或业务中能够接受或不能接受的功能，因此，即便服务器端相应业务的功能发生变化，也不会影响用户对先前版本业务的使用，另外终端或服务器不再需要针对并存业务中的每一个业务设置专用的命令或参数，大大减少了消息体的容量。因此，本实施例提供的上述系统，对业务及业务功能的偏好性协商具有通用性强，兼容性好，通讯效率高的优点。

在实施过程中，第一设备10与第二设备20之间交互的业务协商请求消息和业务协商响应消息，可以采用专设的私有协议的信令，也可以采用现有通信网络中的任何协议的信令，例如，可以但不限于基于SIP协议的初始会话消息。

在实施过程中，设备之间进行上述业务协商，可以是两个设备之间的点对点通信，也可以是两个设备之间通过业务服务器进行业务协商。

如果是点对点通信，则上述系统中的第一设备10与第二设备20可以是两个移动终端设备，两个移动终端设备通过有线局域网进行通信，或通过无线局域网进行通信，例如，两个终端设备通过蓝牙或红外等协议进行通信，协商相应的业务偏好设置，在实施过程中，第一设备10与第二设备20处于对等关系，即任意一端均可以向对端发送业务协商请求消息，作为接收的一端，向发送端反馈业务协商响应消息，完成业务协商。

上述系统中的第一设备10与第二设备20的任意一端也可以是业务服务器，例如第一设备10是业务服务器，第二设备20是与之通信的移动终端，可选的，业务服务器10与另外的移动终端(同样归类为第二设备20)通信，为两个移动终端提供数据连接，业务服务器10通过数据连接分别向两个相互通信的移动终端提供业务数据，在这种应用场景下，业务服务器10作为业务提供网元，与通信的两端移动设备分别协商各自的业务偏好，即无论通信发起端的移动设备还是接收端的移动设备均可以向业务服务器10发送业务协商请求消息。

优选地，上述第一设备10，还用于确定业务协商请求消息指示的业务中存在与本设备相关的业务，并确定能够按照业务协商请求消息的指示提供与本设备相关的业务，以及根据业务协商请求消息的指示，对相关的业务和/或业务中的功能进行剪裁。

在实施过程中，进行业务协商的两端设备，其中必然有一端有决策权，即，当两端设备协商业务时，有决策权的设备端最终决定业务协商结果，一般分为如下两种情况：

(1)发起端第二设备20有决策权，则第一设备10在能够确保第二设备20指示的业务被正常提供的前提下，必须接受第二设备20对业务偏好设置的要求，在业务协商响应消息中通知第一设备10，其接受并提供第二设备20要求的业务及业务中的功能。

(2)接收端第一设备10有决策权，则第一设备10接收到业务协商请求消息后，会判断该业务协商请求消息指示的业务及业务中的功能，是否符合本地的控制逻辑以及业务逻辑，例如，第一设备10为业务服务器的情况下，会判断第二设备20要求的业务及业务中的功能，是否能够使业务正常使用，或者是否符合运营商的规定和利益。

无论上述那种情况，作为接收端的第一设备10都需要检测第二设备20的协商请求消息指示的业务是否与本端相关，还需要检测第二设备20提出的业务要求是否合理，能否按照第二设备20的要求提供可执行的业务，在确定可以按照第二设备20的要求提供相应的业务和业务中的功能后，按照业务协商请求消息的指示对常规业务进行裁剪，以满足第二设备20的需求。

实施例二

在本实施例中，提供一种业务协商方法，应用于实施例一种提供的业务协商系统，图2是根据本发明实施例二的业务协商方法流程图，该方法包括：

步骤S202，第一设备接收来自第二设备的业务协商请求消息，其中，业务协商请求消息用于指示第二设备接受和/或不接受的业务，以及接受的业务中期望接受和/或不接受的功能；

步骤S204，第一设备向第二设备发送业务协商响应消息，其中，协商响应消息用于指示第一设备向第二设备提供和/或不提供的业务，以及提供的业务中能够提供和/或不能够提供的功能。

针对业务或业务能力的偏好设置，相关技术，设备只能进行业务能力级别的偏好设置，不能实现业务级别的协商，对于所有种类的业务来说，存在偏好设置通用性不强，兼容性差，通讯效率低等问题。本实施例提供的上述方法，使得用户期望的业务或者业务功能特征在业务执行之前或执行过程中，可以被实时地协商，不受具体业务特点的限制，例如，多业务并存的情况下，不会屏蔽掉所有业务中的同一个业务功能。再如，某个业务升级后，服务器端增加了新的功能，由于终端用户在业务协商请求消息中指示了能够接受或不能接受的业务或业务中能够接受或不能接受的功能，因此，即便服务器端相应业务的功能发生变化，也不会影响用户对先前版本业务的使用，另外终端或服务器不再需要针对并存业务中的每一个业务设置专用的命令或参数，大大减少了消息体的容量。因此，本实施例提供的上述方法，对业务及业务功能的偏好性协商具有通用性强，兼容性好，通讯效率高的优点。

在实施过程中，第一设备与第二设备之间交互的业务协商请求消息和业务协商响应消息，可以采用专设的私有协议的信令，也可以采用现有通信网络中的任何协议的信令，例如，可以但不限于基于SIP协议的初始会话消息。

如果是点对点通信，则上述方法中的第一设备与第二设备可以是两个移动终端设备，两个移动终端设备通过有线局域网进行通信，或通过无线局域网进行通信，例如，两个终端设备通过蓝牙或红外等协议进行通信，协商相应的业务偏好设置，在实施过程中，第一设备与第二设备处于对等关系，即任意一端均可以向对端发送业务协商请求消息，作为接收的一端，向发送端反馈业务协商响应消息，完成业务协商。

上述方法中的第一设备与第二设备的任意一端也可以是业务服务器，例如第一设备是业务服务器，第二设备是与之通信的移动终端，可选的，业务服务器与另外的移动终端(同样归类为第二设备)通信，为两个移动终端提供数据连接，业务服务器通过数据连接分别向两个相互通信的移动终端提供业务数据，在这种应用场景下，业务服务器作为业务提供网元，与通信的两端移动设备分别协商各自的业务偏好，即无论通信发起端的移动设备还是接收端的移动设备均可以向业务服务器发送业务协商请求消息。

优选地，上述方法还包括：第一设备确定业务协商请求消息指示的业务中存在与本设备相关的业务，并确定能够按照业务协商请求消息的指示提供与本设备相关的业务，以及根据业务协商请求消息的指示，对相关的业务和/或业务中的功能进行剪裁。

在实施过程中，进行业务协商的两端设备，其中有一端有决策权，即，当两端设备协商业务时，有决策权的设备端最终决定业务协商结果，一般分为如下两种情况：

(1)发起端第二设备有决策权，则第一设备在能够确保第二设备指示的业务被正常提供的前提下，必须接受第二设备对业务偏好设置的要求，在业务协商响应消息中通知第一设备，其接受并提供第二设备要求的业务及业务中的功能。

(2)接收端第一设备有决策权，则第一设备接收到业务协商请求消息后，会判断该业务协商请求消息指示的业务及业务中的功能，是否符合本地的控制逻辑以及业务逻辑，例如，第一设备为业务服务器的情况下，会判断第二设备要求的业务及业务中的功能，是否能够使业务正常使用，或者是否符合运营商的规定和利益。

无论上述那种情况，作为接收端的第一设备都需要检测第二设备的协商请求消息指示的业务是否与本端相关，还需要检测第二设备提出的业务要求是否合理，能否按照第二设备的要求提供可执行的业务，在确定可以按照第二设备的要求提供相应的业务和业务中的功能后，按照业务协商请求消息的指示对常规业务进行裁剪，以满足第二设备的需求。

实施例三

针对上述实施例中第一设备作为业务服务器的应用场景，本实施例中提供一种业务协商实施方式，图3是根据本发明实施例三的业务协商处理流程示意图；如图所示，协商业务及业务中功能的相关设备和服务器准备就绪后，开始一个为执行业务建立承载的会话时，进行如下步骤的处理：

步骤S310，会话开始建立，始发设备发送带业务指示的消息；

步骤S320，服务器接收到始发设备发出的消息，判断是否有与本服务器相关的业务指示，如果有，则执行步骤S340，否则，执行步骤S330；

步骤S330，如果消息中没有包含有业务指示，则服务器提供预定义的业务功能，发送消息给接收终端，转步骤S350；

步骤S340，服务器根据业务指示，并根据自身的业务功返回响应消息；并在裁剪业务功能之后开始执行裁剪过的业务逻辑，发送业务消息给接收终端，转步骤S350。

步骤S350，接收终端接收到消息后，在执行业务之前，判断是否要发起这个业务响应，如果是，则执行步骤S370，否则，执行步骤S360；

步骤S360，如果接收终端根据自己的业务环境和/或业务逻辑判定对收到的业务功能消息正常处理就可以了，则回送响应消息、接收并处理业务功能，转步骤S380；

步骤S370：接收终端填写带业务指示的响应，发送给服务器，请求指定的业务功能/业务功能特征，转步骤S380。

步骤S380：其它流程继续进行，有关业务指示的则结束。

上述实施例中，携带于消息中的业务指示、业务功能特征指示，其参数可以事先存储于始发设备、业务应用服务器、接收设备中，由这些设备各自判断并填写信令消息。始发设备、接收设备和服务器都可以设置业务指示、业务功能特征指示，由服务器提供最终的业务功能集。

终端或服务器上可以设置、存储业务指示的策略或参数，这个策略定义可以由终端用户/服务器管理员通过人机界面设置定义，保存在终端/服务器上，当会话开始建立时，由服务器根据来自网络的指示，和本地策略，决定提供业务或业务功能特征，以终端上为例：支持的业务、业务功能标识：由用户自己根据爱好来设定是愿意或拒绝体验某一个或某些业务或业务功能特征，例如，用户可以设定愿意或拒绝体验被叫用户签约的个性化回铃业务，或设定拒绝被叫用户签约的个性化回铃音中的视频特征。

实施例四

在本实施例中，对上述实施例中，用于指示业务或业务中的功能特征的业务协商请求消息以及业务协商响应消息进行详细介绍，重点介绍如何在业务协商请求消息以及业务协商响应消息中设置指示业务偏好的字段，以实现设备间的业务协商。

在上述实施例中，已经提到第一设备与第二设备之间交互的业务协商请求消息和业务协商响应消息，可以采用专设的私有协议的信令，也可以采用现有通信网络中的任何协议的信令，考虑到采用私有协议的信令，虽然可以实现业务偏好的指示和协商，但是其不具有通用性和广泛性，本实施例重点介绍采用现有通信网络中广泛适用的信令，例如，不限于是基于SIP协议的初始会话消息，携带业务及业务中功能的偏好指示。

一种指示业务的方式是，在消息的报文头的字段中指示，例如在SIP消息中使用一个报文头Aceept-Service-List和Refuse-Service-List。具体实现如下：

......

Aceept-Service-List:*；voice

Refuse-Service-List:message

......

这个实施例表示：在这一次会话当中，发起指示一方愿意或能够接受voice这个业务，但不愿意/不能够接受message这个业务。

接收到指示的一方(终端和/或服务器)，根据指示和自身的业务功能给予响应，对所述请求的一种响应是：

Aceept-Service-List:*；voice

Refuse-Service-List:message

......

上述内容包含在响应消息中，表示响应方同意支持voice业务，并且不会与发起方使用message业务。

另一种指示业务的表示方式是，在报文的SDP报文体的字段中指示，例如使用SDP的a行中的CAT属性或KEYWDS属性。这种方法只适于对业务的媒体方面的指示，对那些不使用媒体描述的业务则不适用。具体实现如下：

......

a＝CAT:I_do_not_like_video

......

如前述实施例，接收到指示的一方(终端和/或服务器)，在响应消息中要根据指示和自身的业务功能给予响应。

还有一种指示业务及业务中功能的方式是，添加一种报文体，在报文体中描述接受或描绘的业务或业务功能特征，例如，增加如下的XML报文体：

<？xml version＝″1.0″encoding＝″UTF-8″？>

<service-indication>

<indication-desc>

<service-name>

voice

</service-name>

<refuse-feature>

video

</refuse-feature>

<accept-feature>

audio

</accept-feature>

</indication-desct>

<indication-desc>

<service-name>

CRS

</service-name>

<refuse-feature>

all

</refuse-feature>

</indication-desc>

</service-indication>

该实施例中，指示了两个业务voice和CRS。对voice的业务指示是：不接收视频会话，可以接收音频会话，这里表示的是业务级的指示，并不是媒体能力的描述。对CRS，则是指示拒绝这个业务中的所有功能特征，即表示拒绝这一业务。

上述具体的实施方式既可以在终端上设置，也适于在服务器上设置、使用。

上述实施例适用于3GPP(3rd Generation Partnership Project，第三代合作伙伴计划)的IMS域、3GPP2IMS域，也适用于其它类似网络，如使用SIP作为信令的其它通讯网络。

需要说明的是，对业务协商消息的设置并不是限定只能用上述实施例来实现，也仅不限于在会话的建立时协商，还可以用类似的方式实现，比如更改字段的用法等，那不过是具体的报文内容有所不同。

综上，本发明实施例提供的上述技术方案，通过设备之间进行业务级别的偏好协商，以及具体业务内功能的偏好协商，使得用户期望的业务或者业务功能特征在业务执行之前或执行过程中，可以被实时地协商，不受具体业务特点的限制，例如，多业务并存的情况下，不会屏蔽掉所有业务中的同一个业务功能。再如，某个业务升级后，服务器端增加了新的功能，由于终端用户在业务协商请求消息中指示了能够接受或不能接受的业务或业务中能够接受或不能接受的功能，因此，即便服务器端相应业务的功能发生变化，也不会影响用户对先前版本业务的使用，另外终端或服务器不再需要针对并存业务中的每一个业务设置专用的命令或参数，大大减少了消息体的容量。因此，本实施例提供的上述系统，对业务及业务功能的偏好性协商具有通用性强，兼容性好，通讯效率高的优点。

以上仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims

1.一种业务协商方法，其特征在于，包括：

第一设备接收来自第二设备的业务协商请求消息，其中，所述业务协商请求消息用于指示所述第二设备接受和/或不接受的业务，以及所述接受的业务中接受和/或不接受的功能；

所述第一设备向所述第二设备发送业务协商响应消息，其中，所述协商响应消息用于指示所述第一设备向所述第二设备提供和/或不提供的业务，以及所述提供的业务中提供和/或不提供的功能。

2.根据权利要求1所述的方法，其特征在于，在第一设备向所述第二设备发送业务协商响应消息之前，还包括：

所述第一设备确定所述业务协商请求消息指示的业务中存在与本设备相关的业务；

确定能够按照所述业务协商请求消息的指示提供与本设备相关的业务；

根据所述业务协商请求消息的指示，对相关的业务和/或业务中的功能进行剪裁。

3.根据权利要求1所述的方法，其特征在于，所述第一设备是移动终端，所述第二设备是移动终端或业务服务器。

4.根据权利要求1所述的方法，其特征在于，所述业务协商请求消息是初始会话请求消息，所述业务协商响应消息是初始会话响应消息。

5.根据权利要求4所述的方法，其特征在于，

在所述初始会话请求消息的报文头中设置第一字段，用于指示所述第二设备接受和/或不接受的业务；

在所述初始会话响应消息的报文头中设置第二字段，用于指示所述第一设备向所述第二设备提供和/或不提供的业务。

6.根据权利要求4所述的方法，其特征在于，

在所述初始会话请求消息的报文体中设置第三字段，用于指示所述第二设备接受和/或不接受的业务；

在所述初始会话响应消息的报文体中设置第四字段，用于指示所述第一设备向所述第二设备提供和/或不提供的业务。

7.根据权利要求4所述的方法，其特征在于，

在所述初始会话请求消息的报文体中设置第五字段，用于指示所述第二设备接受的业务中接受和/或不接受的功能；

在所述初始会话响应消息的报文体中设置第六字段，用于指示所述第一设备向所述第二设备提供的业务中提供和/或不提供的功能。

8.根据权利要求4至7任一项所述的方法，其特征在于，所述初始会话请求消息以及所述初始会话响应消息是基于SIP协议的消息。

9.一种业务协商系统，其特征在于，包括：

第二设备，用于向第一设备发送业务协商请求消息，其中，所述业务协商请求消息用于指示所述第二设备接受和/或不接受的业务，以及所述接受的业务中接受和/或不接受的功能；

所述第一设备，用于接收来自所述第二设备的业务协商请求消息，并且向所述第二设备发送业务协商响应消息，其中，所述协商响应消息用于指示所述第一设备向所述第二设备提供和/或不提供的业务，以及所述提供的业务中提供和/或不提供的功能。

10.根据权利要求9所述的系统，其特征在于，所述第一设备还用于确定所述业务协商请求消息指示的业务中存在与本设备相关的业务，并确定能够按照所述业务协商请求消息的指示提供与本设备相关的业务，以及根据所述业务协商请求消息的指示，对相关的业务和/或业务中的功能进行剪裁。