一种D2D发现资源冲突的解决方法与流程

本申请涉及移动通信技术领域，尤其涉及一种设备到设备(D2D，Device to Device)发现资源冲突的解决方法。

背景技术：

现有的LTE系统中，两个用户设备(UE)之间的数据传输都是通过网络侧的中继来实现的，发送端UE首先要将通信数据发送给网络侧，之后网络侧再将该数据转发给接收端UE。即使两个距离很近的UE想要进行通信，那么这些通信数据也要经过网络侧的传递才能发给对方。设备到设备(D2D，Device to Device)技术的引入就是针对发送端UE与接收端UE距离较近的应用场景，此时两个UE之间可以直接传递通信数据，而不再需要网络侧进行中继。引入D2D技术可以减少网络侧的负载，此外，由于两个UE距离较近，可以有效降低UE的发射功率，从而实现节能的目的。为了区别于这种D2D传输技术，以下将原有的通过网络侧中继的传输方式称为蜂窝传输。

现有技术中，一种实现D2D发现的资源分配方式为：网络给所有UE分配共有的资源池，D2D UE自主的从共有的资源池中挑选资源。具体地说，基站(eNB)通过系统信息块(SIB，System Information Block)发给处于连接状态(connected)或空闲状态(Idle)的UE；或者在SIB中指示该eNB支持D2D发现，但是并不提供资源，UE需要转换为CONNECTED状态才能通过专有信令获得发现资源。UE在发现过程中可能会转成Idle，但是完成发现过程后应该会保持connected状态并向网络侧发信令以释放资源。

发明人通过仔细研究，发现现有技术中存在如下问题：

由于所有UE均使用相同的资源池，难免出现冲突，因此UE可能要重复发送多次发现消息给目标UE才可能完成发现，导致D2D传输存在一定的时延。

技术实现要素：

本申请提供了一种D2D发现资源冲突的解决方法，可以解决D2D传输中的资源冲突。

本申请实施例提供的一种设备到设备D2D发现资源冲突的解决方法，包括：

A、网络侧向用户设备发送指示消息；

B、用户设备收到所述指示消息后，向网络侧上报发送D2D发现消息的总次数和D2D发现所使用的总时间；

C、网络侧根据用户设备上报的D2D发现消息的总次数和D2D发现所使用的总时间，估算目前网络侧给当前小区分配的资源池大小是否合适，若是，不进行任何操作，否则网络侧调整SIB中的资源池大小。

较佳地，所述指示消息为系统信息块SIB广播消息。

较佳地，所述SIB广播消息中包含SIB18，SIB18中具有一数据类型为BOOLEAN的新增字段；

步骤B为：用户设备判断所述新增字段的值是否为True，若是，所述用户设备向网络侧上报发送D2D发现消息的总次数和D2D发现所使用的总时间。

较佳地，步骤B所述向网络侧上报发送D2D发现消息的总次数和D2D发现所使用的总时间之前，进一步包括：UE转换为RRC_CONNECTED状态。

较佳地，所述指示消息为RRC专有信令。

较佳地，所述RRC专有信令为RRC连接重配置消息。

较佳地，所述RRC连接重配置消息中包含一数据类型为BOOLEAN的新增字段；

步骤B包括：

B1、用户设备判断RRC连接重配置消息中的所述新增字段的值是否为True，若是，所述用户设备将D2D发现消息的总次数和D2D发现所使用的总时间添加到RRC连接重配置完成消息中；否则不进行任何操作；

B2、用户设备组装出完整的RRC连接重配置完成消息，向网络侧发送所述RRC连接重配置完成消息。

从以上技术方案可以看出，网络侧根据用户设备上报的D2D发现消息的总次数和D2D发现所使用的总时间，估算目前网络侧给当前小区分配的资源池大小是否合适，若是，不进行任何操作，否则网络侧调整SIB中的资源池大小。根据本申请方案，能够解决D2D用户发现资源使用冲突。

附图说明

图1为本申请提供的D2D发现资源冲突的解决方法的基本流程示意图；

图2为本申请实施例一的具体实现流程示意图；

图3为本申请实施例二的具体实现流程示意图。

具体实施方式

本申请提供的D2D发现资源冲突的解决方法的基本流程如图1所示，包括如下步骤：

步骤101：网络侧向用户设备发送指示消息；

步骤102：用户设备收到所述指示消息后，向网络侧上报发送D2D发现消息的总次数和D2D发现所使用的总时间；

步骤103：网络侧根据用户设备上报的D2D发现消息的总次数和D2D发现所使用的总时间，估算目前网络侧给当前小区分配的资源池大小是否合适，若是，不进行任何操作，否则网络侧调整SIB中的资源池大小。

为使本申请技术方案的技术原理、特点以及技术效果更加清楚，以下结合具体实施例对本申请技术方案进行详细阐述。

本申请实施例一中，通过SIB广播消息配置所有UE的上报。

具体地说，在SIB18中增加一个字段：DiscoveryInforReport，数据类型为BOOLEAN；Boolean变量长度为2个字节,但取值只能是True或是False。如果该字段设为True，那么需要UE上报发送D2D发现消息的总次数和D2D发现所使用的总时间。

另外UE需要转换为RRC_CONNECTED状态后再进行上报。

本申请实施例一的具体实现流程如图2所示，包括如下步骤：

步骤201：基站发送SIB广播消息，所述SIB广播消息中包含的SIB18中具有一数据类型为BOOLEAN的新增字段；

步骤202：用户设备接收SIB广播消息；

步骤203：用户设备判断所述SIB广播消息中的SIB18是否包含字段DiscoveryInforReport，并且该字段的值为True，若是，执行步骤204，否则结束本流程；

步骤204：用户设备转换为RRC_CONNECTED状态；

步骤205：用户设备向网络侧上报发送D2D发现消息的总次数和D2D发现所使用的总时间；

步骤206：基站根据用户设备上报的D2D发现消息的总次数和D2D发现所使用的总时间，估算目前基站给当前小区分配的资源池大小是否合适，若是，不进行任何操作，否则基站调整SIB中的资源池大小。

如果基站给当前小区分配的资源池大小合适，则D2D发现消息的总次数和D2D发现所使用的总时间会处于一定的范围。如果基站给当前小区分配的资源池过小，则D2D发现消息的总次数和D2D发现所使用的总时间就会显著增加，因此当这两者超过一个预定阈值，则认为资源池过小，需要增大资源池；反之，如果资源池D2D发现消息的总次数和D2D发现所使用的总时间小于一定的阈值，则资源池过大可能存在资源浪费的情况，需要减小资源池。所述阈值的实际大小需要网络侧根据实际情况和策略进行配置。比如网络侧更看中D2D业务，可以把合适资源池的大小设置大一些；如果更看中蜂窝业务，就把合适资源池的大小设置小一些。

本申请实施例二通过RRC专有信令方式，通知单个UE上报。

具体地说，在RRC连接重配置消息(RRCConnectionReconfiguration)里增加一个字段：DiscoveryInforReport，数据类型为BOOLEAN，如果该字段设为True，那么需要UE上报发送D2D发现消息的总次数和D2D发现所使用的总时间。

本申请实施例二的具体实现流程如图3所示，包括如下步骤：

步骤301：演进的通用陆基无线接入网(EUTRAN)向某一用户设备发送RRC连接重配置消息，所述RRC连接重配置消息中具有一数据类型为BOOLEAN的新增字段；

步骤302：用户设备接收RRC连接重配置消息；

步骤303：用户设备判断所述RRC连接重配置消息中是否包含字段DiscoveryInforReport，并且该字段的值为True，若是，执行步骤304，否则执行步骤305；

步骤304：用户设备将D2D发现消息的总次数和D2D发现所使用的总时间添加到RRC连接重配置完成消息中；

步骤305：用户设备组装出完整的RRC连接重配置完成消息，向EUTRAN发送所述RRC连接重配置完成消息；

步骤306：EUTRAN判断所收到的RRC连接重配置完成消息中是否携带D2D发现消息的总次数和D2D发现所使用的总时间，若是执行步骤307，否则结束本流程。

步骤307：EUTRAN根据用户设备上报的D2D发现消息的总次数和D2D发现所使用的总时间，估算目前给当前小区分配的资源池大小是否合适，若是，不进行任何操作，否则EUTRAN调整SIB中的资源池大小。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请的保护范围，凡在本申请技术方案的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。