CN105338508A - 用于邻近服务的用户设备间发现与通信的方法与装置 - Google Patents

Abstract

本发明的目的是提供一种用于邻近服务的用户设备间发现与通信的方法与装置。本发明通过用户设备与邻近服务网络设备的交互来确定邻近服务的发现条件，进而支持邻近服务的用户设备间可相互发现并进行通信。具体地，用户设备向邻近服务网络设备发送对应于特定应用的邻近服务发现请求，所述邻近服务发现请求还包括所述应用的请求发现条件；接着，邻近服务网络设备检测请求发现条件是否满足邻近服务发现标准；随后，邻近服务网络设备向用户设备发送对应于该应用的邻近服务发现响应，所述邻近服务发现响应还包括该应用的确认发现条件；接着，用户设备基于该应用及其对应的该确认发现条件，执行邻近服务的用户设备间发现与通信。

Description

用于邻近服务的用户设备间发现与通信的方法与装置

技术领域

本发明涉及通信技术领域，尤其涉及一种用于邻近服务的用户设备间发现与通信的技术。

背景技术

3GPP邻近服务(ProximityServices，或者译为接近服务，也可简写为ProSe)，也被称为邻近服务发现与通信，其已经在3GPPTR22.803规范中被研究过，并且TS23.303规范以及TR23.703规范中规定了相应的通信架构和增强功能。图1示出TS23.303规范所提出的邻近服务的通信架构。

邻近服务发现与直接通信可以支持两个或更多个位于直接通信范围中支持邻近服务的用户设备(UserEquipment，简称UE)之间通信路径的发现与建立。邻近服务直接通信路径可以采用E-UTRAN(evolveduniversalterrestrialradioaccessnetwork，演进型通用陆基无线接入网)或WLAN(WirelessLocalAreaNetworks，无线局域网)。

现有技术中，支持邻近服务的用户设备可以基于应用来执行用户设备间发现与通信，所述应用例如QQ、微信、MSN、大众点评、嘀嘀打车等各种应用程序。

对于邻近服务的建立，需要至少一个用户设备发布(announce)其希望用于建立通信的应用的应用编码(applicationcode)，并且需要至少另一个用户设备采用其希望用于建立通信的应用的应用编码来监视(monitor)其它正在发布应用编码的用户设备，为简单起见，将发布应用编码的用户设备简称为发布用户设备(announceUE)，将采用应用编码来进行监视的用户设备简称为监视用户设备(monitorUE)，当发布用户设备所发布的应用编码与监视用户设备所采用的应用编码一致时，发布用户设备和监视用户设备才有可能建立通信。

此外，对于同一个用户设备，其既可以发布应用编码，也可以对应用编码进行监视，而不存在对于一个用户设备仅可以作为发布用户设备或者仅可以作为监视用户设备的限制，并且，发布和监视也可以在同一个用户设备中同时进行。

更具体地，发布用户设备向邻近服务网络设备(ProSefunction)发送邻近服务发布请求，该邻近服务发布请求中包括发布用户设备希望用于建立通信的应用的应用标识(applicationid)，邻近服务网络设备接收邻近服务发布请求，并采用映射算法将应用标识转换为应用编码，接着，邻近服务网络设备向发布用户设备发送邻近服务发现响应，该邻近服务发现响应中包括所转换的应用编码，以供发布用户设备采用该应用编码来进行发布。

相应地，监视用户设备向邻近服务网络设备发送邻近服务监视请求，该邻近服务监视请求中包括监视用户设备希望用于建立通信的应用的应用标识，邻近服务网络设备接收邻近服务监视请求，并采用映射算法将应用标识转换为应用编码，接着，邻近服务网络设备向监视用户设备发送邻近服务发现响应，该邻近服务发现响应中包括所转换的应用编码，以供监视用户设备采用该应用编码来进行监视。

其中，应用标识用于惟一地标识某一应用。邻近服务网络设备采用映射算法将应用标识转换为应用编码的过程意在使邻近服务发现与建立的过程中不会泄露应用标识，以避免泄露用户隐私。邻近服务网络设备位于通信网络中，用于支持邻近服务。

然而，现有技术中邻近服务的用户设备间发现与通信方案具有以下主要缺点：

1)邻近服务发布请求中仅包括发布用户设备希望用于建立通信的应用的应用标识，而其它扩展信息不能被发布，这远远不能满足用户的需求，例如对于社交网络应用(例如MSN、微信、QQ等)，除应用标识以外，用户可能希望发布更多个人的或者商业的偏好信息，诸如性别、年龄等。

2)邻近服务监视请求中仅包括监视用户设备希望用于建立通信的应用的应用标识，而监视用户设备在邻近服务监视过程中仅采用相应的应用编码来监视。在邻近服务监视过程中，监视用户设备不能基于除应用编码以外的其它扩展信息来过滤发布用户设备。

3)现有的发布以及监视的策略仅基于支持邻近服务的用户设备所提供的信息来确定，例如，邻近服务发布请求中仅包括应用标识，则相应的邻近服务发现响应中则仅包括应用编码，据此，发布用户设备将仅发布应用编码，而如果大多数监视用户设备采用应用编码以及其它扩展信息一并来监视，则仅发布应用编码的发布用户设备不能被这些监视应用编码以及其它扩展信息的监视用户设备发现。因此，寻找匹配的支持邻近服务的用户设备的效率较低。

发明内容

本发明的目的是提供一种用于邻近服务的用户设备间发现与通信的方法与装置。

根据本发明的一个方面，提供了一种在用户设备端用于邻近服务的用户设备间发现与通信的装置，其中，该装置包括：

请求发送装置，用于向邻近服务网络设备发送对应于特定应用的邻近服务发现请求，所述邻近服务发现请求还包括所述应用的请求发现条件；

响应接收装置，用于接收所述邻近服务网络设备返回的对应于所述应用的邻近服务发现响应，所述邻近服务发现响应还包括所述应用的确认发现条件；

ProSe通信装置，用于基于所述应用及其对应的所述确认发现条件，执行邻近服务的用户设备间发现与通信。

根据本发明的另一个方面，还提供了一种在邻近服务网络设备端辅助用户设备间发现与通信的装置，其中，该装置包括：

请求接收装置，用于接收用户设备针对特定应用的邻近服务发现请求，所述邻近服务发现请求还包括所述应用的请求发现条件；

条件检测装置，用于检测所述请求发现条件是否满足邻近服务发现标准；

响应发送装置，用于向所述用户设备发送对应于所述应用的邻近服务发现响应，所述邻近服务发现响应还包括所述应用的确认发现条件，其中，

-当所述请求发现条件满足所述邻近服务发现标准，所述确认发现条件为所述请求发现条件。

-当所述请求发现条件不满足所述邻近服务发现标准，所述确认发现条件通过与所述用户设备协商来确定。

根据本发明的一个方面，还提供了一种在用户设备端用于邻近服务的用户设备间发现与通信的方法，其中，该方法包括：

-向邻近服务网络设备发送对应于特定应用的邻近服务发现请求，所述邻近服务发现请求还包括所述应用的请求发现条件；

-接收所述邻近服务网络设备返回的对应于所述应用的邻近服务发现响应，所述邻近服务发现响应还包括所述应用的确认发现条件；

-基于所述应用及其对应的所述确认发现条件，执行邻近服务的用户设备间发现与通信。

根据本发明的另一个方面，还提供了一种在邻近服务网络设备端辅助用户设备间发现与通信的方法，其中，该方法包括：

a接收用户设备针对特定应用的邻近服务发现请求，所述邻近服务发现请求还包括所述应用的请求发现条件；

b检测所述请求发现条件是否满足邻近服务发现标准；

c向所述用户设备发送对应于所述应用的邻近服务发现响应，所述邻近服务发现响应还包括所述应用的确认发现条件，其中，

-当所述请求发现条件满足所述邻近服务发现标准，所述确认发现条件为所述请求发现条件。

-当所述请求发现条件不满足所述邻近服务发现标准，所述确认发现条件通过与所述用户设备协商来确定。

与现有技术相比，本发明通过用户设备与邻近服务网络设备的交互来实现。具体地，用户设备向邻近服务网络设备发送对应于特定应用的邻近服务发现请求，如邻近服务发布请求或邻近服务监视请求，该邻近服务发现请求除包括现有发现请求中应用的应用标识，还包括该应用的请求发现条件；接着，邻近服务网络设备检测该请求发现条件是否满足邻近服务发现标准；随后，邻近服务网络设备向用户设备发送对应于该应用的邻近服务发现响应，该邻近服务发现响应除包括现有发现响应中应用的应用编码，还包括该应用的确认发现条件，其中，1)当请求发现条件满足邻近服务发现标准，该确认发现条件为该请求发现条件，2)当请求发现条件不满足邻近服务发现标准，该确认发现条件通过与该用户设备协商来确定；接着，用户设备基于该应用及其对应的该确认发现条件，执行邻近服务的用户设备间发现与通信。

根据本发明方案，一方面，除应用标识以外，邻近服务发现请求中还可以包括应用的请求发现条件，该请求发现条件可以是用户指定关于该应用的其它扩展信息，例如，对于社交网络应用，用户可以指定如年龄、性别、国籍、语言等其它扩展信息；另一方面，当所请求的发现条件不满足邻近服务发现标准时，用户设备可以与邻近服务网络设备实时协商来确定应用的发现条件，即确认发现条件，因此用户设备与邻近服务网络设备均可以在协商过程中调整应用的发现条件，通过一轮或多轮协商，本发明可以确定合适的发现条件，从而提高寻找到匹配的用户设备的效率，并且解决了现有技术中发布以及监视的策略仅基于支持邻近服务的用户设备所提供的信息来确定的问题；还一方面，经协商确定的确认发现条件具有一定的价值，邻近服务网络设备可以保存确认发现条件，以作为之后对其他用户设备的邻近服务发现标准，并且，邻近服务网络设备还可以将确认发现条件发送至其它用户设备，并可以用于分类对应相同应用的通信组，进一步地，接受确认发现条件的用户设备可以与确认发现条件的请求用户设备被关联进同一个通信子组中。

附图说明

通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本发明的其它特征、目的和优点将会变得更明显：

图1示出TS23.303规范所提出的邻近服务的通信系统架构图；

图2示出根据本发明一个实施例的一种用于邻近服务的用户设备间发现与通信的方法流程图；

图3示出根据本发明一个更具体的实施例的发布用户设备31发布邻近服务应用的过程；

图4示出根据本发明一个更具体的实施例的监视用户设备41监视邻近服务应用的过程；

图5示出根据本发明一个更具体的实施例的配合来发布邻近服务应用的发布用户设备31和邻近服务网络设备2的装置示意图；

图6示出根据本发明一个更具体的实施例的配合来监视邻近服务应用的发布用户设备41和邻近服务网络设备2的装置示意图。

附图中相同或相似的附图标记代表相同或相似的部件。

具体实施方式

以下在此示出本文中关键术语的中英文对照，以便于阅读和理解相关内容。

邻近服务ProximityServices，简写为ProSe

邻近服务网络设备ProSefunction

用户设备UserEquipment，缩写为UE

发布用户设备announceUE

监视用户设备monitorUE

支持邻近服务的应用/邻近服务应用ProSeapplication

应用标识applicationid

应用编码applicationcode

邻近服务发现条件/发现条件ProSediscoveryrule/discoveryrule

邻近服务发现请求ProSeDiscoverRequest/DiscoverRequest

邻近服务发布请求ProSeAnnounceRequest/AnnounceRequest

邻近服务监视请求ProSeMonitorRequest/MonitorRequest

最佳邻近服务发现标准optimizedProSediscoverycriteria

邻近服务发现响应ProSeDiscoveryResponse

建议发现条件suggestedApplicationDiscoveryCriteria

下面结合附图对本发明作进一步详细描述。

图1示出当前邻近服务的通信系统架构图。

如图1所示，邻近服务网络设备(ProSeFunction)是指位于通信网络中用于邻近服务的设备，其与一个或多个网元相连接，这些网元诸如支持邻近服务的各应用的应用服务器、HSS(HomeSubscriberServer，归属用户服务器)、SLP(ServiceLocationProtocol，服务定位协议)，其中HSS可以连接MME(MobilityManagementEntity，移动管理实体)、S/PGW(ServiceGateway/PacketGateway，服务网关/分组数据网网关)等网关设备，邻近服务网络设备可以通过与这些网元的交互来获取信息。

支持邻近服务的应用的应用服务器也与用户设备中的邻近服务应用通过PC1接口相连接。

用户设备A、用户设备B与邻近服务网络设备相连接(其中用户设备B与邻近服务网络设备之间的通信路径未示出)，并分别地向邻近服务网络设备发送对应于特定应用的邻近服务发现请求，随后，用户设备A、用户设备B分别地接收邻近服务网络设备返回的对应于该应用的邻近服务发现响应，接着，用户设备A、用户设备B分别地进行该邻近服务应用的发布/监视，进而执行邻近服务的用户设备间发现与通信。

其中，邻近服务发现请求/邻近服务发现响应将通过PC3接口来在用户设备与邻近服务网络设备之间进行传递。

进一步地，本发明基于现有的邻近服务通信架构，提供了一种增强的用于邻近服务的用户设备间发现与通信的方案。具体地，用户设备向邻近服务网络设备发送对应于特定应用的邻近服务发现请求，如邻近服务发布请求或邻近服务监视请求，该邻近服务发现请求还包括该应用的请求发现条件；接着，邻近服务网络设备检测所请求的请求发现条件是否满足邻近服务发现标准；随后，邻近服务网络设备向用户设备发送对应于该应用的邻近服务发现响应，该邻近服务发现响应还包括该应用的确认发现条件，其中，1)当请求发现条件满足邻近服务发现标准，确认发现条件为请求发现条件，2)当请求发现条件不满足邻近服务发现标准，确认发现条件通过与该用户设备协商来确定；接着，用户设备基于该应用及其对应的确认发现条件，执行邻近服务的用户设备间发现与通信。

本发明适用于支持邻近服务的用户设备，无论其是否由E-UTRAN提供服务，以及漫游场景。

在此，用户设备包括但不限于任何一种可与用户通过键盘、触摸板以及声控设备等输入设备进行人机交互的电子产品，例如手机、智能手机、平板电脑等。并且，对用户设备需做广义理解，即用户设备不仅限于由用户随身持有的设备，还包括由用户配置完成并且装置在特定位置的设备，诸如装置在超市货架、饭店、商场、地铁站等任何地点的支持邻近服务的设备。

其中，应用的发现条件可以表现为任何形式，例如，对于QQ和微信(这两种应用在中国广为使用并且非常流行。微信具有4亿用户)，存在多种属性来指示用户，诸如年龄、性别、城市等，从而相应的发现条件可以如“年龄＝20”、“年龄>20”、“年龄<30”、“性别＝男”、“性别＝女”，“城市＝北京”等。再如，对于大众点评、美团等应用，相应的发现条件可以如“人均消费＝50”、“人均消费<100”、“卫生等级>B”等。

图2示出根据本发明一个实施例的一种用于邻近服务的用户设备间发现与通信的方法流程图。

在步骤S201中，用户设备1向邻近服务网络设备2发送对应于特定应用的邻近服务发现请求，所述邻近服务发现请求还包括所述应用的请求发现条件，相应地，邻近服务网络设备2接收邻近服务发现请求；在步骤S202中，邻近服务网络设备2检测所述请求发现条件是否满足邻近服务发现标准；在步骤S203中，邻近服务网络设备2向用户设备1发送对应于该应用的邻近服务发现响应，所述邻近服务发现响应还包括该应用的确认发现条件，相应地，用户设备1接收邻近服务发现响应，其中，1)当请求发现条件满足邻近服务发现标准，所述确认发现条件为所述请求发现条件，2)当请求发现条件不满足邻近服务发现标准，所述确认发现条件通过与该用户设备1协商来确定；在步骤S204中，用户设备1基于该应用及其对应的所述确认发现条件，执行邻近服务的用户设备间发现与通信。

在步骤S201中，用户设备1向邻近服务网络设备2发送对应于特定应用的邻近服务发现请求(ProSeDiscoverRequest)，该邻近服务发现请求还包括所述应用的请求发现条件；相应地，邻近服务网络设备2接收邻近服务发现请求。

在此，当用户设备1为发布用户设备时，其所发送的邻近服务发现请求为邻近服务发布请求(AnnounceRequest)；当用户设备1为监视用户设备时，其所发送的邻近服务发现请求为邻近服务监视请求(MonitorRequest)。

邻近服务发现请求中不仅包括TS23.303规范所规定的邻近服务基本信息，如邻近服务应用标识(applicationID)，用户设备标识(UEIdentity)、发布命令(announcecommand)或者监视命令(monitorcommand)、应用识别信息(applicationidentity)，还包括应用的请求发现条件，即用户设备1对邻近服务应用所指定的其他发现条件。更具体地，对于发布用户设备，其请求发现条件即为请求来用于对特定应用进行邻近服务发布的发现条件；对于监视用户设备，其请求发现条件即为请求来用于对特定应用进行邻近服务监视的发现条件。

请求发现条件可以为一条发现条件，如“年龄＝20”；请求发现条件也可以为多条发现条件，并表现为一个列表，如“年龄＝20”、“城市＝北京”、“性别＝男”。

请求发现条件可以采用一种新的参数ApplicationDiscoveryCriteria来定义/携带，并被包含在邻近服务发现请求中，以发送至邻近服务网络设备2。

邻近服务网络设备2接收邻近服务发现请求后，可以根据邻近服务发现请求中所包含的发布命令或监视命令，来判断出用户设备1是邻近服务的发布用户设备，还是邻近服务的监视用户设备。

在步骤S202中，邻近服务网络设备2检测所请求的请求发现条件是否满足邻近服务发现标准。

在此，对于支持邻近服务的用户设备，其可以基于任何支持邻近服务的应用来发布或监视，并且，其可以发布或监视任何形式的发现条件；但是，对于发布用户设备与监视用户设备，只有发布的应用与监视的应用一致，并且发布用户设备所发布的发现条件与监视用户设备所监视的发现条件相匹配时，该发布用户设备与该监视用户设备才有可能发现彼此。

其中，发布用户设备所发布的发现条件与监视用户设备所监视的发现条件相匹配是指，两者的发现条件的属性相同且具体值相匹配。例如，发布用户设备A发布的发现条件为“年龄＝20”&“城市＝北京”，监视用户设备B监视的发现条件为“年龄<30”&“城市＝北京”，则发布用户设备A所发布的发现条件与监视用户设备B所监视的发现条件相匹配；再如，监视用户设备C监视的发现条件为“性别＝男”&“城市＝北京”，则发布用户设备A所发布的发现条件与监视用户设备C所监视的发现条件不相匹配。

因此，为提高用户设备寻找到相匹配的用户设备的效率，邻近服务网络设备2可以检测请求发现条件是否满足邻近服务发现标准，如最佳邻近服务发现标准(optimizedProSediscoverycriteria)。

在此，对于不同应用，其所对应的邻近服务发现标准是不尽相同的，邻近服务网络设备2需检测请求发现条件是否满足该应用所对应的邻近服务发现标准。

其中，邻近服务发现标准至少可基于以下内容来确定：

1)所请求应用所对应的邻近服务发现条件。

邻近服务发现条件可以为一条或多条，其可以为邻近服务网络设备2所预置的，也可以由邻近服务网络设备2咨询其它网元来获得，其中，所述其它网元包括但不限于运营商所提供的功能性网元，以及第三方的应用服务器，所述功能性网元包括但不限于HSS、PCRF(PolicyandChargingRulesFunction，策略与计费规则功能单元)等，所述第三方的应用服务器可以为各邻近服务应用的应用服务器。网络设备2可以在本地保存一个预置的邻近服务发现条件列表，以用于判断用户设备1所发送的请求发现条件是否满足该列表中的各项发现条件。又如，邻近服务网络设备2咨询用户设备1所请求的邻近服务应用的应用服务器，以获得该应用服务器所返回的最佳邻近服务发现条件。再如，邻近服务网络设备2咨询HSS来获得如用户设备1所在的当前区域的邻近服务发现条件。

邻近服务网络设备2可通过判断请求发现条件是否与相应应用的邻近服务发现条件相匹配，来检测请求发现条件是否满足邻近服务发现标准，当相匹配时，请求发现条件满足邻近服务发现标准；当不相匹配时，请求发现条件不满足邻近服务发现标准。

进一步地，邻近服务网络设备2分别确定对应于发布用户设备的邻近服务发现条件，以及对应于监视用户设备的邻近服务发现条件。

对于邻近服务的发布用户设备所发起的邻近服务发布请求，邻近服务网络设备2将监视用户设备针对相应应用所采用的邻近服务发现条件作为邻近服务发现标准，并据此确定发布用户设备的请求发现条件是否满足邻近服务发现标准。

对于邻近服务的监视用户设备所发起的邻近服务监视请求，邻近服务网络设备2将发布用户设备针对相应应用所采用的邻近服务发现条件作为邻近服务发现标准，并据此确定监视用户设备的请求发现条件是否满足邻近服务发现标准。

2)所请求应用所对应的邻近服务发现条件的使用率。

邻近服务网络设备2可以统计支持邻近服务的用户设备对应同一种应用所采用的发现条件，从而确定其中每种邻近服务发现条件的使用率。

例如，支持邻近服务的用户设备中对应于同一邻近服务应用的用户设备有10000个，其中8000个用户设备采用“性别”这一属性作为一条发现条件，则该发现条件“性别”的使用率为80％，其中6000个用户设备采用“所在地”这一属性作为一条发现条件，则该发现条件“所在地”的使用率为60％。

邻近服务网络设备2可以预设邻近服务发现条件的使用率所对应的阈值，或者，邻近服务网络设备2可以将所请求应用的所有发现条件的平均使用率作为该阈值。

例如，邻近服务网络设备2可以基于相应应用所对应的每种邻近服务发现条件的使用率，来确定所有邻近服务发现条件的平均使用率，如72％，并将其作为邻近服务发现条件的使用率阈值，进而计算请求发现条件的平均使用率，如果所计算的平均使用率大于或等于该阈值，则请求发现条件满足邻近服务发现标准；如果所计算的平均使用率小于该阈值，则请求发现条件满足邻近服务发现标准。

具体地，例如，既前例，请求发现条件包括“性别＝男”&“所在地＝北京”这两条发现条件，其中，发现条件“性别”的使用率为80％，发现条件“所在地”的使用率为70％，因此，请求发现条件的平均使用率为75％，该平均使用率大于阈值72％，因此，请求发现条件满足邻近服务发现标准。

又如，邻近服务网络设备2预设一个邻近服务发现条件的使用率阈值，该阈值可区分应用来设定，或适用于所有应用。邻近服务网络设备2获得请求发现条件中每条的使用率，并逐个与该阈值来进行比较，如请求发现条件中所有发现条件的使用率均超过该阈值时，则认为请求发现条件满足邻近服务发现标准，如请求发现条件中至少有一条发现条件的使用率未超过该阈值，则认为请求发现条件不满足邻近服务发现标准。

具体地，例如，请求发现条件包括“性别＝男”&“所在地＝北京”这两条发现条件，其中，发现条件“性别”的使用率为80％，发现条件“所在地”的使用率为70％，预定的使用率阈值为50％，故两条发现均超过该阈值，因此，请求发现条件满足邻近服务发现标准。

进一步地，邻近服务网络设备2分别统计对应于发布用户设备的每种发现条件的使用率，以及对应于监视用户设备的每种发现条件的使用率。

对于邻近服务的发布用户设备所发起的邻近服务发布请求，邻近服务网络设备2根据监视用户设备针对相应应用所采用的每种发现条件的使用率来确定请求发现条件的平均使用率，并据此确定发布用户设备的请求发现条件是否满足邻近服务发现标准。

对于邻近服务的监视用户设备所发起的邻近服务监视请求，邻近服务网络设备2根据发布用户设备针对相应应用所采用的每种发现条件的使用率来确定请求发现条件的平均使用率，并据此确定监视用户设备的请求发现条件是否满足邻近服务发现标准。

优选地，用户设备1的请求发现条件可以仅满足邻近服务发现条件或其使用率所对应的阈值中之一，也可以需两者均满足。

例如，请求发现条件与邻近服务发现条件相匹配，或请求发现条件的平均使用率超过相应阈值，皆可确定请求发现条件满足邻近服务发现标准；或者，请求发现条件不仅需与邻近服务发现条件相匹配，且请求发现条件的平均使用率需超过相应阈值，才可确定请求发现条件满足邻近服务发现标准。

在步骤S203中，邻近服务网络设备2向用户设备1发送对应于所请求应用的邻近服务发现响应，该邻近服务发现响应还包括该应用的确认发现条件；相应地，用户设备1接收邻近服务发现响应。

在此，对于发布用户设备的邻近服务发布请求，邻近服务网络设备2的邻近服务发现响应(ProSeDiscoveryResponse)中的确认发现条件由新参数ProSeApplicationCriteriaCode来携带/定义；对于监视用户设备的邻近服务监视请求，邻近服务网络设备2的邻近服务发现响应中的确认发现条件由新参数ProSeApplicationCriteriaFilter来携带/定义。

其中，除了现有规范中所规定的应用编码(applicationcode)，邻近服务发现响应还包括所请求应用的确认发现条件。应用编码是基于映射算法从应用标识转换获得的。确认发现条件可包括一条或多条，其可能与请求发现条件相一致，也可能不一致。进一步地，确认发现条件可以采用映射算法进行转换，也可以不进行映射转换，并且，确认发现条件采用的映射算法可以与应用编码的映射算法相同。

在此，邻近服务网络设备2根据请求发现条件是否满足邻近服务发现标准，来确定相应应用的确认发现条件。具体地：

1)当请求发现条件满足邻近服务发现标准，应用的确认发现条件即为请求发现条件。

在此，由于请求发现条件满足邻近服务发现标准，邻近服务网络设备2直接将请求发现条件作为确认发现条件，并据此返回相应的邻近服务发现响应。

2)当请求发现条件不满足邻近服务发现标准，应用的确认发现条件通过邻近服务网络设备2与用户设备1协商来确定。

其中，协商的具体过程如下：

x、邻近服务网络设备2向用户设备1发送对应于该应用的建议发现条件(suggestedApplicationDiscoveryCriteria)，相应地，用户设备1接收建议发现条件。

其中，建议发现条件可以为一条或多条发现条件，其确定方式至少可有以下几种：

i可基于请求发现条件中每条发现条件的使用率来确定，如删除其中使用率低于阈值的发现条件，并将剩余发现条件作为建议发现条件。

ii可基于所请求应用所对应的预设发现条件确定，并将预设发现条件中的全部或部分作为建议发现条件。例如，每个应用所对应的预设发现条件可从其他网元，如相应应用的应用服务器，获得。

iii可基于用户设备1所属的通信组/通信子组所采用的发现条件确定，并将其所属通信组/通信子组中其他用户设备所采用的发现条件的全部或部分作为建议发现条件。其中，支持相同邻近服务应用的用户设备属于同一通信组，这些用户设备中采用相同发现条件的用户设备进一步属于同一通信子组。

在此，建议发现条件也通过ApplicationDiscoveryCriteria参数由邻近服务网络设备2传递给用户设备1。

y、用户设备1向邻近服务网络设备2反馈建议发现条件中可接受的发现条件，相应地，邻近服务网络设备2接收该反馈。

在此，用户设备1可以接受建议发现条件中的全部或部分发现条件，也可以拒绝建议发现条件中的所有发现条件，并反馈给邻近服务网络设备2。

用户设备1可以根据其接受的发现条件来更新请求发现条件。例如，用户设备1将其接受的部分或全部建议发现条件作为更新的请求发现条件反馈给邻近服务网络设备2，或者，用户设备1在拒绝全部建议发现条件时，重新提交更新的请求发现条件，并且，此时更新的请求发现条件仍可与邻近服务发现请求中的请求发现条件一致。其中，用户设备1所反馈的请求发现条件仍通过ApplicationDiscoveryCriteria参数传递给邻近服务网络设备2。

用户设备1具体选择接受建议发现条件中的发现条件、或者拒绝建议发现条件中的发现条件取决于用户设备1的设置。

以上x、y的步骤可以循环执行一次或多次，也即，用户设备1与邻近服务网络设备2之间的协商可以进行一轮或多轮。在此，一轮协商意指邻近服务网络设备2在一次建议发现条件的确定过程中，为用户设备1所确定的建议发现条件全部已经过协商。

例如，当建议发现条件包括多条发现条件时，邻近服务网络设备2可以一次仅发送其中一条发现条件，从而x、y步骤被重复多次进行，当所有发现条件均发送至用户设备1，并接收到用户设备1的反馈时，此轮协商过程才结束；随后，邻近服务网络设备2可以开始下一轮的协商过程或终止协商，这取决于协商相关的设置。

又如，第一轮协商时，邻近服务网络设备2发送一条或多条发现条件，用户设备1拒绝该(等)发现条件，第二轮协商时，邻近服务网络设备2发送其他发现条件，以供用户设备1接受或拒绝，从而x、y步骤被循环执行多次。其中，每轮协商中提供的建议发现条件可以完全不同，也可以部分相同。

协商过程的终止可从以下两种情形确定：

1)双方协商一致。

例如，用户设备1接受邻近服务网络设备2提供的建议发现条件。又如，用户设备1基于建议发现条件所反馈的请求发现条件，被邻近服务网络设备2接受，此时用户设备1反馈更新的请求发现条件可以为建议发现条件中的部分或全部，也可以是用户设备1重新提交的请求发现条件。再如，双方第一轮协商失败，在第二轮协商中，用户设备1仍坚持最初的请求发现条件，邻近服务网络设备2接受，此时也可认为双方协商一致。

2)双方协商未果。

例如，当协商开始时，邻近服务网络设备2可以开启计时器，当计时器达到预定时间期间时，双方仍未达成一致，邻近服务网络设备2可以停止与用户设备1的协商，此时双方协商未果。又如，当用户设备1多次拒绝建议发现条件时，拒绝次数超出预定值，邻近服务网络设备2可以停止与用户设备的协商，此时双方同样协商未果。

当协商未能达成一致时，确认发现条件可为用户设备1最初在邻近服务发现请求中提交的请求发现条件，虽然请求发现条件未满足邻近服务发现标准，用户设备1寻找匹配的用户设备的效率可能较低，但仍然保证了用户设备1可以进行邻近服务应用的发布或监视。

优选地，邻近服务网络设备2可以先检测所请求应用是否支持确认发现条件的协商，若是，则执行与用户设备1之间关于确定发现条件的协商。

具体地，邻近服务网络设备2可基于至少以下3种方式来检测支持协商的邻近服务应用：

1)应用标识(applicationid)；邻近服务网络设备2可以保存有支持协商的应用的应用标识，这些应用标识可以由支持协商的邻近服务应用的应用服务器预先向邻近服务网络设备2注册和/或支持邻近服务的用户设备向邻近服务网络设备2上报其中支持协商的邻近服务应用。因此，邻近服务网络设备2可以查询其保存的支持协商的应用的应用标识，来确定用户设备1所请求的应用是否支持确认发现条件的协商。

2)用户设备标识(UEidentity)；支持邻近服务的发现条件协商的用户设备可以预先向邻近服务网络设备2注册，因此，邻近服务网络设备2可以查询其保存的支持协商的用户设备的用户设备标识，来确定用户设备1(所请求的应用)是否支持确认发现条件的协商。

3)应用标识和用户设备标识；各支持邻近服务的用户设备可将其自身中支持协商的邻近服务应用上报给邻近服务网络设备2，从而邻近服务网络设备2可保存支持协商的用户设备的用户设备标识以及其中每个用户设备中支持协商的邻近服务应用的应用标识，并可据此进行查询。

当接收到对应特定应用的邻近服务发现请求时，邻近服务网络设备2可以检测该应用是否支持确认发现条件的协商；或者，当请求发现条件不满足邻近服务发现标准时，邻近服务网络设备2检测该应用是否支持确认发现条件的协商。

优选地，邻近服务网络设备2可以保存邻近服务发现响应所对应的确认发现条件，以作为相应应用的邻近服务发现条件和/或用于统计相应应用的邻近服务发现条件的使用率。

并且，邻近服务网络设备2还可以将所请求应用的确认发现条件分配至其它用户设备。由于确认发现条件是经协商后的发现条件，具有一定价值，因此，邻近服务网络设备2可以将确认发现条件分配至其它用户设备，例如其他具有任何相同的属性的用户设备，所述相同属性例如相同的用户设备位置、相同的通信时间等。

进一步地，邻近服务网络设备2可以将确认发现条件分配至所请求应用所对应的其他用户设备，这些支持相同应用的用户设备处于同一个通信组中，但其中的用户设备可能尚未支持发起包括请求发现条件的邻近服务发现请求。

因此，当这些用户设备接收到确认发现条件后，其中部分或全部用户设备保存确认发现条件以供日后发起邻近服务发现请求使用，这些接受确认发现条件的用户设备将向邻近服务网络设备2上报自身，相应地，邻近服务网络设备2可以将保存确认发现条件的用户设备与发起邻近服务发现请求的用户设备进一步关联进一个通信子组中。

在步骤S204中，用户设备1基于该应用及其对应的确认发现条件，执行邻近服务的用户设备间发现与通信。

具体地，发布用户设备基于所请求应用的应用编码以及该应用的确认发现条件将该应用作为邻近服务应用进行发布。例如，发布用户设备将邻近服务应用的应用编码及其经确认的发现条件承载在PC5参考点上进行发布，以供其他监视该邻近服务应用且采用相同发现条件作为过滤条件的监视用户设备可以发现该发布用户设备并建立通信。

监视用户设备基于所请求应用的应用编码以及该应用的确认发现条件将该应用作为邻近服务应用进行监视。例如，监视用户设备在PC5参考点上监视该邻近服务应用的应用编码并将其经确认的发现条件作为过滤条件来监视其他处于直接通信范围内的发布用户设备，进而发现相匹配的发布用户设备并与之建立通信。

相匹配的支持邻近服务的用户设备间进行通信的方式包括但不限于以下2种：

1)监视用户设备中呈现匹配的多个发布用户设备，用户可选择其中一个或多个发布用户设备建立通信。

例如，发布用户设备11采用QQ的应用编码及确认发现条件“性别＝男”&“所在地＝北京”&“年龄＝25”进行发布；发布用户设备12采用QQ的应用编码及确认发现条件“性别＝男”&“所在地＝北京”&“年龄＝30”进行发布；发布用户设备13采用QQ的应用编码及确认发现条件“性别＝男”&“所在地＝北京”&“年龄＝18”进行发布；监视用户设备14采用QQ的应用编码及确认发现条件“性别＝男”&“所在地＝北京”&“年龄<28”进行监视；监视用户设备15采用QQ的应用编码及确认发现条件“性别＝男”&“所在地＝北京”&“年龄＝25”进行监视。

据此，监视用户设备14中呈现发布用户设备11和发布用户设备13；监视用户设备15中呈现发布用户设备11。监视用户设备14和15的用户可以选择发布用户设备来建立通信。

2)监视用户设备可以直接与匹配的发布用户设备建立通信并接收消息。

例如，一超市中具有发布用户设备21、发布用户设备22、发布用户设备23，其中，发布用户设备21采用大众点评的应用编码及确认发现条件“所在地＝超市”&“种类＝食品”&“折扣＝8折”进行发布；发布用户设备22采用大众点评的应用编码及确认发现条件“所在地＝超市”&“种类＝食品”&“折扣＝7折”进行发布；发布用户设备23采用大众点评的应用编码及确认发现条件“所在地＝超市”&“种类＝生活用品”&“折扣＝无”进行发布；而用户采用其监视用户设备24进行监视，并监视大众点评的应用编码及确认发现条件“所在地＝超市”&“种类＝食品”&“折扣<9折”。

据此，监视用户设备24寻找到匹配的发布用户设备21、发布用户设备22之后，监视用户设备24直接与之建立连接并接收信息，例如监视用户设备24接收到发布用户设备21发送的信息“伊利果子面包买4送1，就在食品区第4货架”，以及发布用户设备22发送的信息“蒙牛牛奶促销，仅此一天，就在食品区第9货架”。

图3示出根据本发明一个更具体的实施例的邻近服务应用发布过程，其中具体示出发布用户设备31与邻近服务网络设备2协商应用的确认发现条件并发布邻近服务应用。

在步骤301中，发布用户设备31被授权来发布其自身，发布用户设备31被触发与邻近服务网络设备2建立安全连接并且发送邻近服务发布请求，邻近服务发布请求中包括邻近服务基本信息，如邻近服务应用标识，用户设备标识、发布命令、应用识别信息，以及应用的请求发现条件；相应地，邻近服务网络设备2接收该邻近服务发布请求。

其中，参数ApplicationDiscoveryCriteria被引入以携带请求发现条件。

在步骤302中，邻近服务网络设备2检测请求发现条件是否满足邻近服务发现标准，结果为不满足。

如果需要，邻近服务网络设备2也可以与其它网元通信，以获取邻近服务网络设备2所需要的信息，例如从HSS获取发布用户设备31所在地的邻近服务发现标准。

在步骤303中，邻近服务网络设备2向发布用户设备31发送对应于该应用的建议发现条件；相应地，发布用户设备31接收建议发现条件。

在步骤304中，发布用户设备31检验建议发现条件并且确定建议发现条件中可接受的发现条件。如果完成，将更新的请求发现条件写入ApplicationDiscoveryCriteria参数中，从而发送回邻近服务网络设备2。

需要注意的是，步骤303和步骤304的协商过程可以进行多轮。

在步骤305中，当协商完成时，邻近服务网络设备2采用邻近服务发现响应来回应发布用户设备3，邻近服务发现响应中包括应用编码以及确认发现条件，以用于确认发布用户设备31拟用于发布邻近服务应用的发现条件。其中，确认发现条件可以由参数ProSeApplicationCriteriaCode来携带。

在此，在协商达成一致时，确认发现条件应与最后从发布用户设备31接收的请求发现条件相一致，而不能再单独地被邻近服务网络设备2改变。

在步骤306中，发布用户设备31开始采用应用编码以及所确认的发现条件来发布邻近服务应用。

图4示出根据本发明一个更具体的实施例的邻近服务应用监视过程，其中具体示出监视用户设备41与邻近服务网络设备2协商应用的确认发现条件并监视邻近服务应用。

在步骤401中，监视用户设备41被授权来监视并且监视特定应用，监视用户设备41与邻近服务网络设备2建立安全连接并且发送邻近服务监视请求，邻近服务监视请求中包括邻近服务基本信息，如邻近服务应用标识，用户设备标识、监视命令、应用识别信息，邻近服务监视请求中还包括应用的请求发现条件；相应地，邻近服务网络设备2接收邻近服务监视请求。

参数ApplicationDiscoveryCriteria被引入以携带请求发现条件。

在步骤402中，邻近服务网络设备2检测请求发现条件是否满足邻近服务发现标准，结果为不满足。

如果需要，邻近服务网络设备2也可以与其它网元通信，以获取邻近服务网络设备2所需要的信息，如监视用户设备41所在地的邻近服务发现标准。

在步骤403中，邻近服务网络设备2向监视用户设备41发送对应于该应用的建议发现条件；相应地，监视用户设备4接收建议发现条件。

在步骤404中，监视用户设备41检验建议发现条件并且确定建议发现条件中可接受的发现条件。如果完成，将更新的请求发现条件写入ApplicationDiscoveryCriteria参数中，从而发送回邻近服务网络设备2。

需要注意的是，步骤403和步骤404的协商过程可以进行多轮。

在步骤405中，当协商完成时，邻近服务网络设备2采用邻近服务发现响应来回应监视用户设备4，邻近服务发现响应中包括应用编码以及确认发现条件，以用于确认监视用户设备41拟用于监视邻近服务应用的发现条件。其中，确认发现条件可以由参数ProSeApplicationCriteriaFilter来携带。

在此，在协商达成一致时，确认发现条件应与最后从监视用户设备41接收的请求发现条件相一致，而不能再单独地被邻近服务网络设备2改变。

在步骤406中，监视用户设备41开始采用应用编码以及确认发现条件在无线资源中来进行邻近服务应用的监视，无线资源如RAN(RadioAccessNetwork，无线接入网)规范中所定义的，由PLMN(PublicLandMobileNetwork，公共陆地移动网络)授权并且配置以用于支持邻近服务。

图5示出根据本发明一个更具体的实施例的配合来协商应用的确认发现条件并发布邻近服务应用的发布用户设备51与邻近服务网络设备2的装置示意图。

如图5所示，发布用户设备51包括第一请求发送装置511、第一响应接收装置512和第一ProSe通信装置513；邻近服务网络设备2包括请求接收装置521、条件检测装置522和响应发送装置513。

具体地，发布用户设备51被授权来发布其自身，发布用户设备51被触发与邻近服务网络设备2建立安全连接，第一请求发送装置511向邻近服务网络设备2发送邻近服务发布请求，邻近服务发布请求中除包括TS23.303所规定的邻近服务基本信息，如邻近服务应用标识，用户设备标识、发布命令、应用识别信息，该邻近服务发布请求中还包括应用的请求发现条件；相应地，邻近服务网络设备2的请求接收装置521接收该邻近服务发布请求。

其中，参数ApplicationDiscoveryCriteria被引入以携带请求发现条件。

接收邻近服务发现请求后，请求接收装置521可以根据邻近服务发现请求中所包含的发布命来判断出用户设备51是邻近服务的发布用户设备。

随后，邻近服务网络设备2的条件检测装置522检测请求发现条件是否满足邻近服务发现标准。

在此，对于不同应用，其所对应的邻近服务发现标准是不尽相同的，条件检测装置522需检测请求发现条件是否满足该应用所对应的邻近服务发现标准。

其中，邻近服务发现标准至少可基于以下内容来确定：

1)所请求应用所对应的邻近服务发现条件。

邻近服务发现条件可以为一条或多条，其可以为条件检测装置522或邻近服务网络设备2中的其他特定装置所预置的，也可以由条件检测装置522或邻近服务网络设备2中的其他特定装置咨询其它网元来获得，其中，所述其它网元包括但不限于运营商所提供的功能性网元，以及第三方的应用服务器，所述功能性网元包括但不限于HSS、PCRF等，所述第三方的应用服务器可以为各邻近服务应用的应用服务器。例如，邻近服务网络设备2可以在本地保存一个预置的邻近服务发现条件列表，以用于判断发布用户设备51所发送的请求发现条件是否满足该列表中的各项发现条件。又如，邻近服务网络设备2咨询发布用户设备51所请求的邻近服务应用的应用服务器，以获得该应用服务器所返回的最佳邻近服务发现条件。再如，邻近服务网络设备2咨询HSS来获得如发布用户设备51所在的当前区域的邻近服务发现条件。

条件检测装置522可通过判断请求发现条件是否与相应应用的邻近服务发现条件相匹配，来检测请求发现条件是否满足邻近服务发现标准，当相匹配时，请求发现条件满足邻近服务发现标准；当不相匹配时，请求发现条件不满足邻近服务发现标准。

进一步地，对于邻近服务的发布用户设备所发起的邻近服务发布请求，条件检测装置522可将监视用户设备针对相应应用所采用的邻近服务发现条件作为邻近服务发现标准，并据此确定发布用户设备的请求发现条件是否满足邻近服务发现标准。

2)所请求应用所对应的邻近服务发现条件的使用率。

条件检测装置522或邻近服务网络设备2中的其他特定装置可以统计支持邻近服务的用户设备对应同一种应用所采用的发现条件，从而确定其中每种邻近服务发现条件的使用率。

例如，支持邻近服务的用户设备中对应于同一邻近服务应用的用户设备有10000个，其中8000个用户设备采用“性别”这一属性作为一条发现条件，则该发现条件“性别”的使用率为80％，其中6000个用户设备采用“所在地”这一属性作为一条发现条件，则该发现条件“所在地”的使用率为60％。

条件检测装置522或邻近服务网络设备2中的其他特定装置可以预设邻近服务发现条件的使用率所对应的阈值，或者，条件检测装置522或邻近服务网络设备2中的其他特定装置可以将所请求应用的所有发现条件的平均使用率作为该阈值。

例如，邻近服务网络设备2可以基于相应应用所对应的每种邻近服务发现条件的使用率，来确定所有邻近服务发现条件的平均使用率，如72％，并将其作为邻近服务发现条件的使用率阈值，进而条件检测装置522计算请求发现条件的平均使用率，如果该平均使用率大于或等于该阈值，则请求发现条件满足邻近服务发现标准；如果该平均使用率小于该阈值，则请求发现条件满足邻近服务发现标准。

具体地，例如，既前例，请求发现条件包括“性别＝男”&“所在地＝北京”这两条发现条件，其中，发现条件“性别”的使用率为80％，发现条件“所在地”的使用率为70％，因此，请求发现条件的平均使用率为75％，该平均使用率大于阈值72％，因此，条件检测装置522可确定请求发现条件满足邻近服务发现标准。

又如，邻近服务网络设备2预设一个邻近服务发现条件的使用率阈值，该阈值可区分应用来设定，或适用于所有应用。条件检测装置522获得请求发现条件中每条的使用率，并逐个与该阈值来进行比较，如请求发现条件中所有发现条件的使用率均超过该阈值时，则认为请求发现条件满足邻近服务发现标准，如请求发现条件中至少有一条发现条件的使用率未超过该阈值，则认为请求发现条件不满足邻近服务发现标准。

具体地，例如，请求发现条件包括“性别＝男”&“所在地＝北京”这两条发现条件，其中，发现条件“性别”的使用率为80％，发现条件“所在地”的使用率为70％，预定的使用率阈值为50％，故两条发现均超过该阈值，因此，条件检测装置522可确定请求发现条件满足邻近服务发现标准。

进一步地，对于邻近服务的发布用户设备所发起的邻近服务发布请求，条件检测装置522或邻近服务网络设备2根据监视用户设备针对相应应用所采用的每种发现条件的使用率来确定请求发现条件的平均使用率，并据此确定发布用户设备51的请求发现条件是否满足邻近服务发现标准。

优选地，发布用户设备51的请求发现条件可以仅满足邻近服务发现条件或其使用率所对应的阈值中之一，也可以需两者均满足。

例如，请求发现条件与邻近服务发现条件相匹配，或请求发现条件的平均使用率超过相应阈值，皆可确定请求发现条件满足邻近服务发现标准；或者，请求发现条件不仅需与邻近服务发现条件相匹配，且请求发现条件的平均使用率需超过相应阈值，才可确定请求发现条件满足邻近服务发现标准。

邻近服务网络设备2的响应发送装置523向发布用户设备51发送对应于所请求应用的邻近服务发现响应，该邻近服务发现响应还包括该应用的确认发现条件；相应地，发布用户设备51的第一响应接收装置513接收邻近服务发现响应。

在此，对于发布用户设备51的邻近服务发布请求，邻近服务发现响应(ProSeDiscoveryResponse)除了现有规范中所规定的应用编码(applicationcode)，还包括所请求应用的确认发现条件，其由参数ProSeApplicationCriteriaCode来携带/定义。其中，应用编码是基于映射算法从应用标识转换获得的。确认发现条件可包括一条或多条，其可能与请求发现条件相一致，也可能不一致。进一步地，确认发现条件可以采用映射算法进行转换，也可以不进行映射转换，并且，确认发现条件采用的映射算法可以与应用编码的映射算法相同。

在此，响应发送装置523根据请求发现条件是否满足邻近服务发现标准，来确定相应应用的确认发现条件。具体地：

1)当请求发现条件满足邻近服务发现标准，应用的确认发现条件即为请求发现条件。

在此，由于请求发现条件满足邻近服务发现标准，响应发送装置523直接将请求发现条件作为确认发现条件，并据此返回相应的邻近服务发现响应。

2)当请求发现条件不满足邻近服务发现标准，应用的确认发现条件通过邻近服务网络设备2与发布用户设备51协商来确定。

其中，协商的具体过程如下：

x、响应发送装置523或邻近服务网络设备2的其他特定装置向用户设备1发送对应于该应用的建议发现条件(suggestedApplicationDiscoveryCriteria)，相应地，发布用户设备1的第一请求协商装置(未示出)接收建议发现条件。

其中，建议发现条件可以为一条或多条发现条件，其确定方式至少可有以下几种：

i可基于请求发现条件中每条发现条件的使用率来确定，如删除其中使用率低于阈值的发现条件，并将剩余发现条件作为建议发现条件。

ii可基于所请求应用所对应的预设发现条件确定，并将预设发现条件中的全部或部分作为建议发现条件。例如，每个应用所对应的预设发现条件可从其他网元，如相应应用的应用服务器，获得。

iii可基于发布用户设备51所属的通信组/通信子组所采用的发现条件确定，并将其所属通信组/通信子组中其他用户设备所采用的发现条件的全部或部分作为建议发现条件。其中，支持相同邻近服务应用的用户设备属于同一通信组，这些用户设备中采用相同发现条件的用户设备进一步属于同一通信子组。

在此，建议发现条件也通过ApplicationDiscoveryCriteria参数由邻近服务网络设备2传递给发布用户设备51。

y、发布用户设备51的第一请求协商装置向邻近服务网络设备2反馈建议发现条件中可接受的发现条件，相应地，响应发送装置523或邻近服务网络设备2的其他特定装置接收该反馈。

在此，发布用户设备51可以接受建议发现条件中的全部或部分发现条件，也可以拒绝建议发现条件中的所有发现条件，并反馈给邻近服务网络设备2。

发布用户设备51可以根据其接受的发现条件来更新请求发现条件。例如，第一请求协商装置将其接受的部分或全部建议发现条件作为更新的请求发现条件反馈给邻近服务网络设备2，或者，第一请求协商装置在拒绝全部建议发现条件时，重新提交更新的请求发现条件，并且，此时更新的请求发现条件仍可与邻近服务发现请求中的请求发现条件一致。其中，发布用户设备51的第一请求协商装置所反馈的请求发现条件仍通过ApplicationDiscoveryCriteria参数传递给邻近服务网络设备2。

发布用户设备51具体选择接受建议发现条件中的发现条件、或者拒绝建议发现条件中的发现条件取决于发布用户设备51的设置。

以上x、y的步骤可以循环执行一次或多次，也即，发布用户设备51与邻近服务网络设备2之间的协商可以进行一轮或多轮。在此，一轮协商意指邻近服务网络设备2在一次建议发现条件的确定过程中，为发布用户设备51所确定的建议发现条件全部已经过协商。其中，每轮协商中提供的建议发现条件可以完全不同，也可以部分相同。

协商过程的终止可从以下两种情形确定：

1)双方协商一致。

例如，发布用户设备51接受邻近服务网络设备2提供的建议发现条件。又如，发布用户设备51基于建议发现条件所反馈的请求发现条件，被邻近服务网络设备2接受，此时发布用户设备51反馈更新的请求发现条件可以为建议发现条件中的部分或全部，也可以是发布用户设备51重新提交的请求发现条件。再如，双方第一轮协商失败，在第二轮协商中，发布用户设备51仍坚持最初的请求发现条件，邻近服务网络设备2接受，此时也可认为双方协商一致。

2)双方协商未果。

例如，当协商开始时，邻近服务网络设备2可以开启计时器，当计时器达到预定时间期间时，双方仍未达成一致，邻近服务网络设备2可以停止与发布用户设备51的协商，此时双方协商未果。又如，当发布用户设备51多次拒绝建议发现条件时，拒绝次数超出预定值，邻近服务网络设备2可以停止与发布用户设备51的协商，此时双方同样协商未果。

当协商未能达成一致时，确认发现条件可为发布用户设备51最初在邻近服务发现请求中提交的请求发现条件，虽然请求发现条件未满足邻近服务发现标准，发布用户设备51寻找匹配的用户设备的效率可能较低，但仍然保证了发布用户设备51可以进行邻近服务应用的发布或监视。

优选地，邻近服务网络设备2还包括应用检测装置(未示出)，应用检测装置可以先检测所请求应用是否支持确认发现条件的协商，若是，则执行与发布用户设备51之间关于确定发现条件的协商。

具体地，应用检测装置可基于至少以下3种方式来检测支持协商的邻近服务应用：

1)应用标识(applicationid)；邻近服务网络设备2可以保存有支持协商的应用的应用标识，这些应用标识可以由支持协商的邻近服务应用的应用服务器可以预先向邻近服务网络设备2注册和/或支持邻近服务的用户设备向邻近服务网络设备2上报其中支持协商的邻近服务应用。因此，应用检测装置可以查询邻近服务网络设备2保存的支持协商的应用的应用标识，来确定发布用户设备51所请求的应用是否支持确认发现条件的协商。

2)用户设备标识(UEidentity)；支持邻近服务的发现条件协商的用户设备可以预先向邻近服务网络设备2注册，因此，应用检测装置可以查询邻近服务网络设备2保存的支持协商的用户设备的用户设备标识，来确定用户设备1(所请求的应用)是否支持确认发现条件的协商。

3)应用标识和用户设备标识；各支持邻近服务的用户设备可将其自身中支持协商的邻近服务应用上报给邻近服务网络设备2，从而邻近服务网络设备2可保存支持协商的用户设备的用户设备标识以及其中每个用户设备中支持协商的邻近服务应用的应用标识，应用检测装置可据此进行查询。

当接收到对应特定应用的邻近服务发现请求时，应用检测装置可以检测该应用是否支持确认发现条件的协商；或者，当请求发现条件不满足邻近服务发现标准时，应用检测装置检测该应用是否支持确认发现条件的协商。

最后，发布用户设备51的第一ProSe通信装置513开始采用邻近服务发现响应中的应用编码以及所确认的发现条件来发布邻近服务应用。

优选地，邻近服务网络设备2可以保存邻近服务发现响应所对应的确认发现条件，以作为相应应用的邻近服务发现条件和/或用于统计相应应用的邻近服务发现条件的使用率。

并且，邻近服务网络设备2的条件分配装置(未示出)还可以将所请求应用的确认发现条件分配至其它用户设备。由于确认发现条件是经协商后的发现条件，具有一定价值，因此，条件分配装置可以将确认发现条件分配至其它用户设备，例如其他具有任何相同的属性的用户设备，所述相同属性例如相同的用户设备位置、相同的通信时间等。

进一步地，条件分配装置可以将确认发现条件分配至所请求应用所对应的其他用户设备，这些支持相同应用的用户设备处于同一个通信组中，但其中的用户设备可能尚未支持发起包括请求发现条件的邻近服务发现请求。

因此，当这些用户设备接收到确认发现条件后，其中部分或全部用户设备保存确认发现条件以供日后发起邻近服务发现请求使用，这些接受确认发现条件的用户设备将向邻近服务网络设备2上报自身，相应地，邻近服务网络设备2的设备分组装置(未示出)可以将保存确认发现条件的用户设备与发起邻近服务发现请求的用户设备进一步关联进一个通信子组中。

图6示出根据本发明一个更具体的实施例的配合来协商应用的确认发现条件并监视邻近服务应用的监视用户设备61与邻近服务网络设备2的装置示意图。

如图6所示，监视用户设备61包括第二请求发送装置611、第二响应接收装置612和第二ProSe通信装置613；邻近服务网络设备2包括请求接收装置621、条件检测装置622和响应发送装置613。

具体地，监视用户设备61被授权来监视并且监视特定应用，监视用户设备61被触发与邻近服务网络设备2建立安全连接，第二请求发送装置611向邻近服务网络设备2发送邻近服务发布请求，邻近服务发布请求中除包括TS23.303所规定的邻近服务基本信息，如邻近服务应用标识，用户设备标识、监视命令、应用识别信息，该邻近服务发布请求中还包括应用的请求发现条件；相应地，邻近服务网络设备2的请求接收装置621接收该邻近服务发布请求。

其中，参数ApplicationDiscoveryCriteria被引入以携带请求发现条件。

接收邻近服务发现请求后，请求接收装置621可以根据邻近服务发现请求中所包含的监视命令来判断出用户设备61是邻近服务的监视用户设备。

随后，邻近服务网络设备2的条件检测装置622检测请求发现条件是否满足邻近服务发现标准。

在此，对于不同应用，其所对应的邻近服务发现标准是不尽相同的，条件检测装置622需检测请求发现条件是否满足该应用所对应的邻近服务发现标准。

其中，邻近服务发现标准至少可基于以下内容来确定：

1)所请求应用所对应的邻近服务发现条件。

邻近服务发现条件可以为一条或多条，其可以为条件检测装置622或邻近服务网络设备2中的其他特定装置所预置的，也可以由条件检测装置622或邻近服务网络设备2中的其他特定装置咨询其它网元来获得，其中，所述其它网元包括但不限于运营商所提供的功能性网元，以及第三方的应用服务器，所述功能性网元包括但不限于HSS、PCRF等，所述第三方的应用服务器可以为各邻近服务应用的应用服务器。例如，邻近服务网络设备2可以在本地保存一个预置的邻近服务发现条件列表，以用于判断监视用户设备61所发送的请求发现条件是否满足该列表中的各项发现条件。又如，邻近服务网络设备2咨询监视用户设备61所请求的邻近服务应用的应用服务器，以获得该应用服务器所返回的最佳邻近服务发现条件。再如，邻近服务网络设备2咨询HSS来获得如监视用户设备61所在的当前区域的邻近服务发现条件。

条件检测装置622可通过判断请求发现条件是否与相应应用的邻近服务发现条件相匹配，来检测请求发现条件是否满足邻近服务发现标准，当相匹配时，请求发现条件满足邻近服务发现标准；当不相匹配时，请求发现条件不满足邻近服务发现标准。

进一步地，对于邻近服务的监视用户设备所发起的邻近服务发布请求，条件检测装置622可将发布用户设备针对相应应用所采用的邻近服务发现条件作为邻近服务发现标准，并据此确定监视用户设备61的请求发现条件是否满足邻近服务发现标准。

2)所请求应用所对应的邻近服务发现条件的使用率。

条件检测装置622或邻近服务网络设备2中的其他特定装置可以统计支持邻近服务的用户设备对应同一种应用所采用的发现条件，从而确定其中每种邻近服务发现条件的使用率。

例如，支持邻近服务的用户设备中对应于同一邻近服务应用的用户设备有10000个，其中8000个用户设备采用“性别”这一属性作为一条发现条件，则该发现条件“性别”的使用率为80％，其中6000个用户设备采用“所在地”这一属性作为一条发现条件，则该发现条件“所在地”的使用率为60％。

条件检测装置622或邻近服务网络设备2中的其他特定装置可以预设邻近服务发现条件的使用率所对应的阈值，或者，条件检测装置622或邻近服务网络设备2中的其他特定装置可以将所请求应用的所有发现条件的平均使用率作为该阈值。

例如，邻近服务网络设备2可以基于相应应用所对应的每种邻近服务发现条件的使用率，来确定所有邻近服务发现条件的平均使用率，如72％，并将其作为邻近服务发现条件的使用率阈值，进而条件检测装置622计算请求发现条件的平均使用率，如果该平均使用率大于或等于该阈值，则请求发现条件满足邻近服务发现标准；如果该平均使用率小于该阈值，则请求发现条件满足邻近服务发现标准。

具体地，例如，既前例，请求发现条件包括“性别＝男”&“所在地＝北京”这两条发现条件，其中，发现条件“性别”的使用率为80％，发现条件“所在地”的使用率为70％，因此，请求发现条件的平均使用率为75％，该平均使用率大于阈值72％，因此，条件检测装置622可确定请求发现条件满足邻近服务发现标准。

又如，邻近服务网络设备2预设一个邻近服务发现条件的使用率阈值，该阈值可区分应用来设定，或适用于所有应用。条件检测装置622获得请求发现条件中每条的使用率，并逐个与该阈值来进行比较，如请求发现条件中所有发现条件的使用率均超过该阈值时，则认为请求发现条件满足邻近服务发现标准，如请求发现条件中至少有一条发现条件的使用率未超过该阈值，则认为请求发现条件不满足邻近服务发现标准。

具体地，例如，请求发现条件包括“性别＝男”&“所在地＝北京”这两条发现条件，其中，发现条件“性别”的使用率为80％，发现条件“所在地”的使用率为70％，预定的使用率阈值为50％，故两条发现均超过该阈值，因此，条件检测装置622可确定请求发现条件满足邻近服务发现标准。

进一步地，对于邻近服务的监视用户设备所发起的邻近服务发布请求，邻近服务网络设备2根据发布用户设备针对相应应用所采用的每种发现条件的使用率来确定请求发现条件的平均使用率，并据此确定监视用户设备61的请求发现条件是否满足邻近服务发现标准。

优选地，监视用户设备61的请求发现条件可以仅满足邻近服务发现条件或其使用率所对应的阈值中之一，也可以需两者均满足。

例如，请求发现条件与邻近服务发现条件相匹配，或请求发现条件的平均使用率超过相应阈值，皆可确定请求发现条件满足邻近服务发现标准；或者，请求发现条件不仅需与邻近服务发现条件相匹配，且请求发现条件的平均使用率需超过相应阈值，才可确定请求发现条件满足邻近服务发现标准。

邻近服务网络设备2的响应发送装置623向监视用户设备61发送对应于所请求应用的邻近服务发现响应，该邻近服务发现响应还包括该应用的确认发现条件；相应地，监视用户设备61的第二响应接收装置613接收邻近服务发现响应。

在此，对于监视用户设备61的邻近服务监视请求，邻近服务发现响应(ProSeDiscoveryResponse)除了现有规范中所规定的应用编码(applicationcode)，还包括所请求应用的确认发现条件，其由参数ProSeApplicationCriteriaFilter来携带/定义。其中，应用编码是基于映射算法从应用标识转换获得的。确认发现条件可包括一条或多条，其可能与请求发现条件相一致，也可能不一致。进一步地，确认发现条件可以采用映射算法进行转换，也可以不进行映射转换，并且，确认发现条件采用的映射算法可以与应用编码的映射算法相同。

在此，响应发送装置623根据请求发现条件是否满足邻近服务发现标准，来确定相应应用的确认发现条件。具体地：

1)当请求发现条件满足邻近服务发现标准，应用的确认发现条件即为请求发现条件。

在此，由于请求发现条件满足邻近服务发现标准，响应发送装置623直接将请求发现条件作为确认发现条件，并据此返回相应的邻近服务发现响应。

2)当请求发现条件不满足邻近服务发现标准，应用的确认发现条件通过邻近服务网络设备2与监视用户设备61协商来确定。

其中，协商的具体过程如下：

x、响应发送装置623或邻近服务网络设备2的其他特定装置向用户设备1发送对应于该应用的建议发现条件(suggestedApplicationDiscoveryCriteria)，相应地，监视用户设备61的第二请求协商装置(未示出)接收建议发现条件。

其中，建议发现条件可以为一条或多条发现条件，其确定方式至少可有以下几种：

i可基于请求发现条件中每条发现条件的使用率来确定，如删除其中使用率低于阈值的发现条件，并将剩余发现条件作为建议发现条件。

ii可基于所请求应用所对应的预设发现条件确定，并将预设发现条件中的全部或部分作为建议发现条件。例如，每个应用所对应的预设发现条件可从其他网元，如相应应用的应用服务器，获得。

iii可基于监视用户设备61所属的通信组/通信子组所采用的发现条件确定，并将其所属通信组/通信子组中其他用户设备所采用的发现条件的全部或部分作为建议发现条件。其中，支持相同邻近服务应用的用户设备属于同一通信组，这些用户设备中采用相同发现条件的用户设备进一步属于同一通信子组。

在此，建议发现条件也通过ApplicationDiscoveryCriteria参数由邻近服务网络设备2传递给监视用户设备61。

y、监视用户设备61的第二请求协商装置向邻近服务网络设备2反馈建议发现条件中可接受的发现条件，相应地，响应发送装置623或邻近服务网络设备2的其他特定装置接收该反馈。

在此，监视用户设备61可以接受建议发现条件中的全部或部分发现条件，也可以拒绝建议发现条件中的所有发现条件，并反馈给邻近服务网络设备2。

监视用户设备61可以根据其接受的发现条件来更新请求发现条件。例如，第二请求协商装置将其接受的部分或全部建议发现条件作为更新的请求发现条件反馈给邻近服务网络设备2，或者，第二请求协商装置在拒绝全部建议发现条件时，重新提交更新的请求发现条件，并且，此时更新的请求发现条件仍可与邻近服务发现请求中的请求发现条件一致。其中，监视用户设备61的第二请求协商装置所反馈的请求发现条件仍通过ApplicationDiscoveryCriteria参数传递给邻近服务网络设备2。

监视用户设备61具体选择接受建议发现条件中的发现条件、或者拒绝建议发现条件中的发现条件取决于监视用户设备61的设置。

以上x、y的步骤可以循环执行一次或多次，也即，监视用户设备61与邻近服务网络设备2之间的协商可以进行一轮或多轮。在此，一轮协商意指邻近服务网络设备2在一次建议发现条件的确定过程中，为监视用户设备61所确定的建议发现条件全部已经过协商。其中，每轮协商中提供的建议发现条件可以完全不同，也可以部分相同。

协商过程的终止可从以下两种情形确定：

1)双方协商一致。

例如，监视用户设备61接受邻近服务网络设备2提供的建议发现条件。又如，监视用户设备61基于建议发现条件所反馈的请求发现条件，被邻近服务网络设备2接受，此时监视用户设备61反馈更新的请求发现条件可以为建议发现条件中的部分或全部，也可以是监视用户设备61重新提交的请求发现条件。再如，双方第二轮协商失败，在第二轮协商中，监视用户设备61仍坚持最初的请求发现条件，邻近服务网络设备2接受，此时也可认为双方协商一致。

2)双方协商未果。

例如，当协商开始时，邻近服务网络设备2可以开启计时器，当计时器达到预定时间期间时，双方仍未达成一致，邻近服务网络设备2可以停止与监视用户设备61的协商，此时双方协商未果。又如，当监视用户设备61多次拒绝建议发现条件时，拒绝次数超出预定值，邻近服务网络设备2可以停止与监视用户设备61的协商，此时双方同样协商未果。

当协商未能达成一致时，确认发现条件可为监视用户设备61最初在邻近服务发现请求中提交的请求发现条件，虽然请求发现条件未满足邻近服务发现标准，监视用户设备61寻找匹配的用户设备的效率可能较低，但仍然保证了监视用户设备61可以进行邻近服务应用的发布或监视。

优选地，邻近服务网络设备2的应用检测装置可以先检测所请求应用是否支持确认发现条件的协商，若是，则执行与监视用户设备61之间关于确定发现条件的协商。

在此，应用检测装置可同样基于1)应用标识；2)用户设备标识；3)应用标识和用户设备标识之一来检测支持协商的邻近服务应用。

最后，监视用户设备61的第二ProSe通信装置613开始采用应用编码以及确认发现条件在无线资源中来进行邻近服务应用的监视，无线资源如RAN(RadioAccessNetwork，无线接入网)规范中所定义的，由PLMN(PublicLandMobileNetwork，公共陆地移动网络)授权并且配置以用于支持邻近服务。

优选地，邻近服务网络设备2可以保存邻近服务发现响应所对应的确认发现条件，以作为相应应用的邻近服务发现条件和/或用于统计相应应用的邻近服务发现条件的使用率。

并且，邻近服务网络设备2的条件分配装置同样还可以将所请求应用的确认发现条件分配至其它用户设备。进一步地，条件分配装置可以将确认发现条件分配至所请求应用所对应的其他用户设备，这些支持相同应用的用户设备处于同一个通信组中，但其中的用户设备可能尚未支持发起包括请求发现条件的邻近服务发现请求。

当这些用户设备接收到确认发现条件后，其中部分或全部用户设备保存确认发现条件以供日后发起邻近服务发现请求使用，这些接受确认发现条件的用户设备将向邻近服务网络设备2上报自身，邻近服务网络设备2的设备分组装置同样可以将保存确认发现条件的用户设备与发起邻近服务发现请求的用户设备进一步关联进一个通信子组中。

需要注意的是，本发明可在软件和/或软件与硬件的组合体中被实施，例如，可采用专用集成电路(ASIC)、通用目的计算机或任何其他类似硬件设备来实现。

在一个实施例中，本发明的软件程序可以通过处理器执行以实现上文所述步骤或功能。同样地，本发明的软件程序(包括相关的数据结构)可以被存储到计算机可读记录介质中，例如，RAM存储器，磁或光驱动器或软磁盘及类似设备。另外，本发明的一些步骤或功能可采用硬件来实现，例如，作为与处理器配合从而执行各个步骤或功能的电路。

另外，本发明的一部分可被应用为计算机程序产品，例如计算机程序指令，当其被计算机执行时，通过该计算机的操作，可以调用或提供根据本发明的方法和/或技术方案。而调用本发明的方法的程序指令，可能被存储在固定的或可移动的记录介质中，和/或通过广播或其他信号承载媒体中的数据流而被传输，和/或被存储在根据所述程序指令运行的计算机设备的工作存储器中。在此，根据本发明的一个实施例包括一个装置，该装置包括用于存储计算机程序指令的存储器和用于执行程序指令的处理器，其中，当该计算机程序指令被该处理器执行时，触发该装置运行基于前述根据本发明的多个实施例的方法和/或技术方案。

对于本领域技术人员而言，显然本发明不限于上述示范性实施例的细节，而且在不背离本发明的精神或基本特征的情况下，能够以其他的具体形式实现本发明。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本发明的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化涵括在本发明内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。此外，显然“包括”一词不排除其他单元或步骤，单数不排除复数。系统权利要求中陈述的多个单元或装置也可以由一个单元或装置通过软件或者硬件来实现。第一，第二等词语用来表示名称，而并不表示任何特定的顺序。

Claims (18)

1.一种在用户设备端用于邻近服务的用户设备间发现与通信的装置，其中，该装置包括：

请求发送装置，用于向邻近服务网络设备发送对应于特定应用的邻近服务发现请求，所述邻近服务发现请求还包括所述应用的请求发现条件；

响应接收装置，用于接收所述邻近服务网络设备返回的对应于所述应用的邻近服务发现响应，所述邻近服务发现响应还包括所述应用的确认发现条件；

ProSe通信装置，用于基于所述应用及其对应的所述确认发现条件，执行邻近服务的用户设备间发现与通信。

2.根据权利要求1所述的装置，其中，该装置还包括：

请求协商装置，用于当所述请求发现条件不满足邻近服务发现标准时，与所述邻近服务网络设备协商来确定对应于所述应用的确认发现条件。

3.根据权利要求2所述的装置，其中，所述协商进一步包括：

-接收所述邻近服务网络设备返回的对应于所述应用的建议发现条件；

-向所述邻近服务网络设备反馈所述建议发现条件中可接受的发现条件。

4.根据权利要求1至3中任一项所述的装置，其中，所述邻近服务发现请求包括邻近服务发布请求；

其中，所述ProSe通信装置进一步用于：

-基于所述应用及其对应的所述确认发现条件，将所述应用作为邻近服务应用进行发布。

5.根据权利要求1至3中任一项所述的装置，其中，所述邻近服务发现请求包括邻近服务监视请求；

其中，所述ProSe通信装置进一步用于：

-基于所述应用及其对应的所述确认发现条件，将所述应用作为邻近服务应用进行监视。

6.一种在邻近服务网络设备端辅助用户设备间发现与通信的装置，其中，该装置包括：

请求接收装置，用于接收用户设备针对特定应用的邻近服务发现请求，所述邻近服务发现请求还包括所述应用的请求发现条件；

条件检测装置，用于检测所述请求发现条件是否满足邻近服务发现标准；

响应发送装置，用于向所述用户设备发送对应于所述应用的邻近服务发现响应，所述邻近服务发现响应还包括所述应用的确认发现条件，其中，

-当所述请求发现条件满足所述邻近服务发现标准，所述确认发现条件为所述请求发现条件；

-当所述请求发现条件不满足所述邻近服务发现标准，所述确认发现条件通过与所述用户设备协商来确定。

7.根据权利要求6所述的装置，其中，所述协商进一步包括以下操作的一轮或多轮：

-向所述用户设备发送对应于所述应用的建议发现条件；

-接收所述用户设备反馈的所述建议发现条件中可接受的发现条件。

8.根据权利要求6或7所述的装置，其中，当所述协商未能达成一致时，所述确认发现条件为所述请求发现条件。

9.根据权利要求6至8中任一项所述的装置，其中，该装置还包括：

应用检测装置，用于检测所述应用是否支持确认发现条件的协商，若是，则执行所述协商。

10.根据权利要求6至9中任一项所述的装置，其中，所述邻近服务发现标准至少基于以下任一项来确定：

-所述应用所对应的邻近服务发现条件；

-所述应用所对应的邻近服务发现条件的使用率。

11.根据权利要求6至10中任一项所述的装置，其中，所述用户设备包括邻近服务的发布用户设备，其发送的邻近服务发现请求包括邻近服务发布请求；

其中，所述邻近服务发现标准对应于邻近服务的监视用户设备所采用的发现条件。

12.根据权利要求6至11中任一项所述的装置，其中，所述用户设备包括邻近服务的监视用户设备，其发送的邻近服务发现请求包括邻近服务监视请求；

其中，所述邻近服务发现标准对应于邻近服务的发布用户设备所采用的发现条件。

13.根据权利要求6至12中任一项所述的装置，其中，该装置还包括：

条件分配装置，用于将所述邻近服务发现响应所对应的确认发现条件分配至所述应用所对应的其他用户设备。

14.根据权利要求13所述的装置，其中，该装置还包括：

设备分组装置，用于将所述其他用户设备中接受所述确认发现条件的用户设备与所述确认发现条件所对应的请求用户设备分为一个通信子组。

15.一种在用户设备端用于邻近服务的用户设备间发现与通信的方法，其中，该方法包括：

-向邻近服务网络设备发送对应于特定应用的邻近服务发现请求，所述邻近服务发现请求还包括所述应用的请求发现条件；

-接收所述邻近服务网络设备返回的对应于所述应用的邻近服务发现响应，所述邻近服务发现响应还包括所述应用的确认发现条件；

-基于所述应用及其对应的所述确认发现条件，执行邻近服务的用户设备间发现与通信。

16.根据权利要求15所述的方法，其中，该方法还包括：

-当所述请求发现条件不满足邻近服务发现标准时，与所述邻近服务网络设备协商来确定对应于所述应用的确认发现条件。

17.一种在邻近服务网络设备端辅助用户设备间发现与通信的方法，其中，该方法包括：

-接收用户设备针对特定应用的邻近服务发现请求，所述邻近服务发现请求还包括所述应用的请求发现条件；

-检测所述请求发现条件是否满足邻近服务发现标准；

-向所述用户设备发送对应于所述应用的邻近服务发现响应，所述邻近服务发现响应还包括所述应用的确认发现条件，其中，

-当所述请求发现条件满足所述邻近服务发现标准，所述确认发现条件为所述请求发现条件；

-当所述请求发现条件不满足所述邻近服务发现标准，所述确认发现条件通过与所述用户设备协商来确定。

18.根据权利要求17所述的方法，其中，所述协商进一步包括以下过程的一次或多次：

-向所述用户设备发送对应于所述应用的建议发现条件；

-接收所述用户设备反馈的所述建议发现条件中可接受的发现条件。