专利名称：一种实现用户间协作的方法及系统的制作方法
技术领域：
本发明涉及无线通信技术，尤指一种实现用户间协作的方法及系统。
背景技术：
随着移动通信网络的技术发展和用户业务需求的多样化，用户希望通过移动无线 网络体验多媒体广播组播类型业务的需求日益明显，例如手机电视、天气预报、新闻和杂志 等业务。多媒体广播组播业务的特点在于所需传输带宽高，占用大量无线资源；面向服务的 用户数多，而不仅仅针对个别用户。然而，无线蜂窝网络中通常采用点到点的专用信道方式提供业务，因此，对于大数 据量的多媒体广播组播业务而言会出现成本高、业务资费昂贵、规模效益差的情况，从而使 得网络运营商难于推广。为了实现在现有蜂窝网络中提供低成本多媒体业务的目标，引入 了多播广播业务来承载此类业务。多播广播业务(MBS，Multicast Broadcast Service)是从一个数据源向多个 目标传送数据的技术，能够提高网络资源，尤其是空中接口资源的利用率，目前使用的较 为广泛的是多媒体广播组播业务(MBMS)、增强型多播业务(E-MBS，Enhanced multicast broadcast service)等。图1为现有用户终端接收MBS业务的示意图，如图1所示，系统在 发射MBS业务时，接收业务的一组用户即UE1、UE2和UE3会接收相同的业务。MBS业务的承 载可以采用两种方式一种是专用载波方式，即MBS业务独占某个载波上的所有时频资源； 另一种方式是共享载波方式，即MBS业务与单播业务共享载波上的时频资源。随着多媒体 共享业务的应用推广，高效地进行多播和广播业务传输对于下一代宽带移动通信系统变得 尤为重要。目前，接收相同MBS业务的一组用户之间是各自独立完成自身的业务接收的。在 某用户出现接收错误，或者认为接收到的业务数据不能满足自身的服务质量(QoS)要求 时，该用户只能丢弃该包或通过重传机制重新获得所需的业务数据。在存在多个用户都需 要重传时，需要占用较多资源，同时无法保证上行传输的可靠性；如果没有重传机制，那么， 用户就不能正确接收业务，降低了用户的QoS，影响了用户对业务的接收效果和用户感受。
发明内容
有鉴于此，本发明的主要目的在于提供一种实现用户间协作的方法，能够实现对 接收相同业务的用户进行协作，保证用户正确接收业务，提高用户的QoS，提高用户的感受。本发明的另一目的在于提供一种实现用户间协作的系统，能够通过接收相同业务 的用户间的协作，保证用户正确接收业务，提高用户的QoS，提高用户的感受。本发明的另一目的在于提供一种实现上行的用户协作的方法，通过用户间的交互 信息，由用户间构成上行虚拟ΜΙΜ0，提高上行链路的可靠性。为达到上述目的，本发明的技术方案是这样实现的一种实现用户间协作的方法，该方法包括以下步骤
根据用户接收业务属性设置用户协作群组；通过寻找协作伙伴，在用户协作群组 中的各用户终端中建立可以协作的用户终端信息；在用户协作群组中存在需要协作的用户终端时，利用该用户协作群组中的其他用 户获取所需业务。在所述用户终端与业务发射端之间存在重传机制时，该方法还包括所述用户终 端通过选择协作用户，建立协作多输入多输出ΜΙΜ0，并通过系统定义的反馈信道或用户专 用上行信道建立上行协作。所述建立上行协作具体包括请求建立上行协作的所述用户终端，将系统分配给自身的上行资源配置信息发送 给被请求建立上行协作的用户终端；被请求建立上行协作的用户终端根据自身上行资源的 占用情况，在自身剩余的上行资源能够满足接收到的资源要求时，向请求建立上行协作的 用户终端回复满足协作要求；如果满足协作条件，则请求建立上行协作的用户终端与被请求建立上行协作的用 户终端之间进行上行协作协商，请求建立上行协作的用户终端将需协作的用户数据发送给 被请求建立上行协作的用户终端，并按照协商好的协作方式进行上行协作；如果不满足协作条件，被请求建立上行协作的用户终端回复不满足协作条件，请 求建立上行协作的用户终端从可以协作的用户终端信息中，重新选择被请求建立上行协作 的用户终端并重新发起上行协作请求。所述上行协作协商的协作方式为采用空频编码/空时编码SFBC/STBC方式，或者 循环延时CDD方式，或者预编码方式，或者天线波束赋形技术。所述用户协作群组包括具有相同接收业务属性的一组用户。所述接收业务属性为相同业务ID，或其他表示相同业务的标识信息。所述用户协作群组中的各用户通过向用户协作群组中的其他用户发起寻找协作 伙伴请求，来建立可协作的用户终端信息，具体包括用户将自身的接收业务属性携带在寻找协作伙伴请求中，发送给所述用户协作群 组中的其他用户，接收到寻找协作伙伴请求的用户比较自身的接收业务属性是否与接收到 的相同，如果相同，则向发起请求的用户回复携带有自身用户终端信息的允许协作应答，发 起请求的用户存储其用户终端信息；如果不相同，则向发起请求的用户回复拒绝协作应答。该方法还包括在所述用户终端中针对不同的业务，预先设置是否愿意作为协作 用户的业务协作标识；在接收到寻找协作伙伴请求的用户比较自身的接收业务属性与接收到的相同时， 如果预先设置的业务协作标识表明对于当前接收业务属性标识的业务，该用户不愿意作为 协作用户，则该用户向发起请求的用户回复拒绝协作应答；如果该用户原意作为协作用户，则该用户保留当前接收正确的数据包，在预设时 间内如果没有其他用户请求协作，则丢弃该包数据；如果有其他用户请求协作，则将该保留 的数据包的部分或全部传给协作用户。该方法还包括所述发起请求的用户对接收到的允许协作应答信号进行测量，并 按照测量得到允许协作应答的用户的信道质量的好坏，对可以协作的用户终端信息按照协 作优先级排列。
在预设周期到来时，或者满足预设时间触发条件时，执行所述寻找协作伙伴的步 骤或更新所述建立的可以协作的用户终端信息。所述协作用户群组中的用户终端之间通过蓝牙、红外、无线局域网或其它用户终 端之间通讯的其它协议或手段进行通信。所述需要协作的用户终端为用户接收业务存在错误的用户终端，或者接收的数 据包无法满足用户的服务质量QoS的用户终端，或者用户希望通过协作提高接收质量的用 户终端。所述利用该用户协作群组中的其他用户获取所需业务具体包括所述需要协作的用户终端从可协作的用户终端信息中选择用户终端，并向选出的 用户终端发起要求共享数据请求；收到要求共享数据请求的用户终端将部分或全部所需业 务数据发送给需要协作的用户终端；所述需要协作的用户终端将接收到的部分或全部业务数据，和已接收到的数据联 合解码，获得正确的所需数据；如果所述需要协作的用户终端在接收到协作用户的数据时仍不能正确解码，选择 向当前返回所需业务数据的用户或用户协作群组中的其他用户，重复发起要求共享数据请 求；当重复次数超出预设重复次数时，终止本次协作请求。所述收到要求共享数据请求的用户终端将部分或全部所需业务数据发送给需要 协作的用户终端之前，该方法还包括所述接收要求共享数据请求的用户终端，根据自身建立的可协作的用户终端信息 判断发起请求的用户终端是否是自身允许协作的用户终端，如果是，将部分或全部所需业 务数据发送给需要协作的用户终端；否则，拒绝请求，所述需要协作的用户终端向用户协作群组中的其他用户发起要 求共享数据请求；当所述接收要求共享数据请求的用户终端自身也需要协作时，拒绝请求。所述业务为多播广播业务MBS、或增强型多播业务E-MBS或多媒体广播组播业务 MBMS0一种实现上行的用户协作的方法，该方法包括以下步骤根据用户接收业务属性设置用户协作群组；通过寻找协作伙伴，在用户协作群组 中的各用户终端中建立可以协作的用户终端信息；在用户协作群组中存在需要协作的用户终端时，利用该用户协作群组中的其他用 户获取所需业务；在所述用户终端与业务发射端之间存在重传机制时，该方法还包括所述用户终 端通过选择协作用户，建立协作多输入多输出ΜΙΜ0，并通过系统定义的反馈信道或用户专 用上行信道建立上行协作。所述建立上行协作具体包括请求建立上行协作的所述用户终端，将系统分配给自身的上行资源配置信息发送 给被请求建立上行协作的用户终端；被请求建立上行协作的用户终端根据自身上行资源的 占用情况，在自身剩余的上行资源能够满足接收到的资源要求时，向请求建立上行协作的用户终端回复满足协作要求；如果满足协作条件，则请求建立上行协作的用户终端与被请求建立上行协作的用 户终端之间进行上行协作协商，请求建立上行协作的用户终端将需协作的用户数据发送给 被请求建立上行协作的用户终端，并按照协商好的协作方式进行上行协作；如果不满足协作条件，被请求建立上行协作的用户终端回复不满足协作条件，请 求建立上行协作的用户终端从可以协作的用户终端信息中，重新选择被请求建立上行协作 的用户终端并重新发起上行协作请求。所述上行协作协商的协作方式为采用空频编码/空时编码SFBC/STBC方式，或者 循环延时CDD方式，或者预编码方式，或者天线波束赋形技术。一种实现用户间协作的系统，该系统包括对小区中的所有用户或一组用户实现业 务链接的基站，其特征在于，该系统还包括两个或两个以上用户终端，其中，用户终端，用于在根据用户接收业务属性设置用户协作群组中，通过寻找协作伙 伴，建立可以协作的用户终端信息，在存在需要协作时，利用该用户终端所在协作群组中的 其他用户获取所需业务。当所述用户协作群组中的用户终端与基站之间存在上行反馈信道时，所述用户终端还用于，通过在用户协作群组中选择协作用户，建立协作ΜΙΜ0，并通 过系统定义的反馈信道或用户专用反馈信道进行上行协作。所述用户协作群组中的用户终端之间通过蓝牙、红外、无线局域网或其它用户终 端之间通讯的其它协议、或其它通信方式进行通信。所述业务为多播广播业务MBS、或增强型多播业务E-MBS或多媒体广播组播业务 MBMS0从上述本发明提供的技术方案可以看出，针对接收相同业务的用户设置用户协作 群组，并通过寻找协作伙伴，在用户协作群组中的各用户终端中建立可以协作的用户终端 信息；在用户协作群组中存在需要协作的用户终端时，利用该用户协作群组中的其他用户 获取所需的部分业务包。通过本发明用户间的协作，保证了用户正确接收业务，提高了用户 的QoS。在用户终端与业务发射端(如基站)之间存在重传机制即上行反馈信道时，可以通 过选择协作用户，建立协作多输入多输出(MIMO)，即虚拟ΜΙΜ0，并通过系统定义的反馈信 道或用户专用上行信道进行上行协作，提高了上行的可靠性，进而保证了系统的整体性能， 提高了用户的感受。
图1为现有用户终端接收MBS业务的示意图；图2为本发明实现用户间协作的方法的流程图；图3为本发明实现用户协作接收EMBS业务的实施例的流程示意图；图4为本发明用户实现上行协作的实施例的流程示意图。
具体实施例方式图2为本发明实现用户间协作的方法的流程图，如图2所示，根据用户终端能力， 用户间交互过程可以是和接收业务同时进行，也可以采用接收业务间隙进行。本发明方法包括以下步骤步骤200 根据用户接收业务属性设置用户协作群组。对于接收相同业务数据的用户，可以根据接收相同业务的一些特殊信息确定用户 协作群组，所述特殊信息是接收业务属性，比如业务ID信息，或者其他表示相同业务的标
识fe息等。步骤201 通过寻找协作伙伴，在用户协作群组中的各用户终端中建立可以协作 的用户终端信息。用户协作群组中的各用户终端之间可以通过蓝牙、红外、无线局域网或其它手段 进行通信，其中，其它手段可以包括用户终端之间通讯的其它协议或手段等。用户协作群组中的各用户通过向用户协作群组中的其他用户发起寻找协作伙伴 请求，来建立可以协作的用户终端信息。具体实现为用户将自身的接收业务属性携带在寻找协作伙伴请求中发送给用户协作群组中 的其他用户，接收到寻找协作伙伴请求的用户比较自身的接收业务属性是否与接收到的相 同，如果相同，则向发起请求的用户回复携带有自身用户终端信息的允许协作应答，发起请 求的用户认为该回复的用户为可以协作的用户并存储其用户终端信息，其中用户终端信息 可以是用户终端ID等信息；如果不相同，则向发起请求的用户回复拒绝协作应答。可以协 作的用户终端信息可以以协作列表的形式存储。进一步地，在用户终端中可以针对不同的业务，预先设置是否愿意作为协作用户 的业务协作标识，在接收到寻找协作伙伴请求的用户比较自身的接收业务属性与接收到的 相同时，如果业务协作标识表明对于当前接收业务属性标识的业务，该用户不愿意作为协 作用户，那么，该用户向发起请求的用户回复拒绝协作应答，如果该用户原意作为协作用 户，则该用户保留当前接收正确的数据包，在预设时间内如果没有用户请求协作，则丢弃该 包数据，如有用户协作则将该数据包的部分或全部传给协作用户。进一步地，发起请求的用户可以对接收到的允许协作应答信号进行测量，并按照 测量得到允许协作应答的用户的信道质量的好坏，对可以协作的用户终端信息按照协作优 先级排列。可以协作的用户终端信息可以采用用户终端列表的形式存储，进一步按照协作优 先级排列。用户终端可以以预设周期方式(预设周期到来时)，或者预设时间触发方式(满足 预设触发条件时)重复步骤201来更新自身存储的可以协作的用户终端信息。步骤202 在用户协作群组中存在需要协作的用户终端时，利用该用户协作群组 中的其他用户获取所需业务。需要协作的用户终端可以是，用户接收业务存在错误时，或者接收的数据包无法 满足用户的QoS时，或者用户希望通过协作提高接收质量时等。需要协作的用户终端可以利用用户协作群组中的其他用户获取所需业务。具体实 现包括需要协作的用户终端从可以协作的用户终端信息中选择用户终端，并向其发起要 求共享数据请求，收到该请求的用户终端将接收的部分或全部所需业务数据发送给需要协 作的用户终端；需要协作的用户终端将接收到的部分或全部业务数据，和已接收到的数据 联合解码，以获得正确的所需数据。之后，可以向发送所需业务数据的用户终端返回正确接收消息。如果需要协作的用户终端在接收到协作用户的数据时仍不能正确解码，可以选择 向当前返回所需业务数据的用户或用户协作群组中的其他用户，重复发起要求共享数据请 求。当重复次数超出预设重复次数时，终止本次协作请求。另外，接收要求共享数据请求的用户终端可以进一步根据自身建立的可协作的用 户终端信息判断发起请求的用户终端是否是自身允许协作的用户终端，如果是，将部分或 全部所需业务数据发送给需要协作的用户终端；否者拒绝请求，此时，要求共享数据的用户 终端回向用户协作群组中的其他用户发起要求共享数据请求。或者，接收要求共享数据请 求的用户终端自身也需要协作时，会拒绝请求。进一步地，本发明方法还可以包括在用户终端与业务发射端(如基站)之间存 在上行反馈信道时，如通过接收到要求共享数据请求的用户不能实现需要协作的用户终端 的正确接收，或者用户协作群组中的部分或所有用户都不能正确接收业务数据时，用户终 端可以通过选择协作用户，建立协作多输入多输出(MIMO)即虚拟ΜΙΜ0，并通过系统定义的 反馈信道或用户专用反馈信道进行上行协作。MIMO方式可以采用现有方式实现，比如空频 编码/空时编码(SFBC/STBC)、循环延时(CDD)、预编码(precoding)或天线波束赋形技术 (beamforming)等，具体实现属于本领域技术人员惯用技术手段，这里不再赘述。其中，建立 上行协作的具体实现包括请求建立上行协作的用户终端，将系统分配给自身的上行资源配置信息发送给被 请求建立上行协作的用户终端；被请求建立上行协作的用户终端根据自身上行资源的占用 情况，在自身剩余的上行资源能够满足接收到的资源要求时，向请求建立上行协作的用户 终端回复满足协作要求；否则回复不满足协作条件，请求建立上行协作的用户终端从可以 协作的用户终端信息中，重新选择被请求建立上行协作的用户终端并重新发起上行协作请 求。如果满足协作条件，则请求建立上行协作的用户终端与被请求建立上行协作的用 户终端之间进行上行协作协商，主要协商协作方式，如协商选择采用SFBC/STBC或CDD或 Precoding或beamforming等，即有协作用户和被协作用户共同按协商的MIMO方式工作。请 求建立上行协作的用户终端将需协作的用户数据发送给被请求建立上行协作的用户终端， 并按照协商好的协作方式进行上行协作。下面以接收EMBS业务为例，结合实施例对本发明方法进行详细描述。目前，协议 中没有确定对于EMBS业务是否需要重传，下面针对需要重传和不需要重传两种情况分别 进行描述。对应本发明方法，还提供一种实现用户间协作的系统，该系统包括用于对小区中 的所有用户或一组用户实现业务链接的基站，以及两个或两个以上用户终端，其中，用户终端，用于在根据用户接收业务属性设置用户协作群组中，通过寻找协作伙 伴，建立可以协作的用户终端信息，在存在需要协作时，利用该用户终端所在协作群组中的 其他用户获取所需业务包。所述用户协作群组中的用户终端之间通过蓝牙、红外、无线局域网或其它用户终 端之间通讯的其它协议、或其它手段等进行通信。当用户协作群组中的用户终端与基站之间存在上行反馈信道时，所述用户终端还用于，通过在用户协作群组中选择协作用户，建立协作ΜΙΜ0，并通过系统定义的反馈信道或 用户专用反馈信道进行上行协作。图3为本发明实现用户协作接收EMBS业务的实施例的流程示意图，假设不存在重 传机制即无EMBS反馈信道，用户A、用户B和用户C属于某用户协作群组，如图3所示，以用 户A发起寻找协作伙伴请求和要求共享数据请求为例，包括步骤300a 用户A向用户B发起寻找协作伙伴请求，寻找协作伙伴请求中携带有 EMBS业务的ID。步骤301a 用户B向用户A返回允许协作应答/拒绝协作应答。本实施例中，假 设用户B比较后得到接收到的EMBS业务的ID与自身的业务ID相同，则向用户A返回允许 协作应答。步骤300b 用户A向用户C发起寻找协作伙伴请求，寻找协作伙伴请求中携带有 EMBS业务的ID。步骤301b 用户C向用户A返回允许协作应答/拒绝协作应答。本实施例中，假 设用户C比较后得到接收到的EMBS业务的ID与自身的业务ID相同，则向用户A返回允许 协作应答。步骤302 用户A根据协作应答情况，建立协作用户终端列表。本实施例中，协作 用户终端列表中包括用户B和用户C。假设用户A在接收应答时，通过测量获知用户B的信 道质量优于用户C的，所以在协作用户终端列表中，用户B的协作优先级高于用户C的。步骤303 步骤304 本实施例中假设用户A接收业务存在错误，向协作优先级高 的用户B发起要求共享数据请求，假设用户B自身也需要协作，用户B向用户A返回拒绝请 求应答。步骤305 步骤306 用户A向用户C发起要求共享数据请求，假设用户C向用户 A返回允许请求应答。步骤307 步骤308 用户C将将部分或全部所需业务数据发送给用户A，用户A 将接收到的部分或全部业务数据，和已接收到的数据联合解码，以获得正确的所需数据。图3所示为不存在重传机制时，通过用户间协作来保证用户正确接收业务的实施 例。如果EMBS业务存在重传机制，当协作用户群组有多个用户存在接收错误时，可以在接 收错误的用户群组之间建立上行协作ΜΙΜ0，以保证上行反馈信道的可靠性。下面结合图4 详细描述上行协作的具体实施例。图4为本发明用户实现上行协作的实施例的流程示意图，假设存在重传机制即有 EMBS反馈信道，用户A和用户B属于某用户协作群组，如图4所示，以用户A发起寻找协作 伙伴请求和要求共享数据请求为例，包括步骤400 用户A向用户B发起寻找协作伙伴请求，寻找协作伙伴请求中携带有 EMBS业务的ID。步骤401 本实施例中，假设用户B比较后得到接收到的EMBS业务的ID与自身的 业务ID相同，用户B向用户A返回允许协作应答。步骤402 用户A根据协作应答情况，建立协作用户终端列表。本实施例中，协作 用户终端列表中包括用户B。步骤403 步骤404 本实施例中假设用户A接收业务存在错误，向协作用户B发起要求共享数据请求，假设用户B自身也需要协作，用户B向用户A返回拒绝请求应答。步骤405 步骤406 用户A向用户B发送上行协作请求，本实施例中，假设用户 B判断出满足协作要求，则在用户A与用户B之间进行上行协作协商，假设协商后得出协作 方式采用CDD方式。步骤407 用户A和用户B采用协商好的协作方式向基站发送协作上行数据，即用 户A发送数据包1，用户B采用频域或时域偏移后发送数据包1。以上所述，仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围，凡在 本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护 范围之内。
权利要求
一种实现用户间协作的方法，其特征在于，该方法包括以下步骤根据用户接收业务属性设置用户协作群组；通过寻找协作伙伴，在用户协作群组中的各用户终端中建立可以协作的用户终端信息；在用户协作群组中存在需要协作的用户终端时，利用该用户协作群组中的其他用户获取所需业务。
2.根据权利要求1所述的方法，其特征在于，在所述用户终端与业务发射端之间存 在重传机制时，该方法还包括所述用户终端通过选择协作用户，建立协作多输入多输出 ΜΙΜ0，并通过系统定义的反馈信道或用户专用上行信道建立上行协作。
3.根据权利要求2所述的方法，其特征在于，所述建立上行协作具体包括请求建立上行协作的所述用户终端，将系统分配给自身的上行资源配置信息发送给被 请求建立上行协作的用户终端；被请求建立上行协作的用户终端根据自身上行资源的占用 情况，在自身剩余的上行资源能够满足接收到的资源要求时，向请求建立上行协作的用户 终端回复满足协作要求；如果满足协作条件，则请求建立上行协作的用户终端与被请求建立上行协作的用户终 端之间进行上行协作协商，请求建立上行协作的用户终端将需协作的用户数据发送给被请 求建立上行协作的用户终端，并按照协商好的协作方式进行上行协作；如果不满足协作条件，被请求建立上行协作的用户终端回复不满足协作条件，请求建 立上行协作的用户终端从可以协作的用户终端信息中，重新选择被请求建立上行协作的用 户终端并重新发起上行协作请求。
4.根据权利要求3所述的方法，其特征在于，所述上行协作协商的协作方式为采用空 频编码/空时编码SFBC/STBC方式，或者循环延时CDD方式，或者预编码方式，或者天线波 束赋形技术。
5.根据权利要求1或2所述的方法，其特征在于，所述用户协作群组包括具有相同接收 业务属性的一组用户。
6.根据权利要求5所述的方法，其特征在于，所述接收业务属性为相同业务ID，或其他 表示相同业务的标识信息。
7.根据权利要求1或2所述的方法，其特征在于，所述用户协作群组中的各用户通过向 用户协作群组中的其他用户发起寻找协作伙伴请求，来建立可协作的用户终端信息，具体 包括用户将自身的接收业务属性携带在寻找协作伙伴请求中，发送给所述用户协作群组中 的其他用户，接收到寻找协作伙伴请求的用户比较自身的接收业务属性是否与接收到的相 同，如果相同，则向发起请求的用户回复携带有自身用户终端信息的允许协作应答，发起请 求的用户存储其用户终端信息；如果不相同，则向发起请求的用户回复拒绝协作应答。
8.根据权利要求7所述的方法，其特征在于，该方法还包括在所述用户终端中针对不 同的业务，预先设置是否愿意作为协作用户的业务协作标识；在接收到寻找协作伙伴请求的用户比较自身的接收业务属性与接收到的相同时，如果 预先设置的业务协作标识表明对于当前接收业务属性标识的业务，该用户不愿意作为协作 用户，则该用户向发起请求的用户回复拒绝协作应答；如果该用户原意作为协作用户，则该用户保留当前接收正确的数据包，在预设时间内如果没有其他用户请求协作，则丢弃该包数据；如果有其他用户请求协作，则将该保留的数 据包的部分或全部传给协作用户。
9.根据权利要求7所述的方法，其特征在于，该方法还包括所述发起请求的用户对接 收到的允许协作应答信号进行测量，并按照测量得到允许协作应答的用户的信道质量的好 坏，对可以协作的用户终端信息按照协作优先级排列。
10.根据权利要求1或2所述的方法，其特征在于，在预设周期到来时，或者满足预设 时间触发条件时，执行所述寻找协作伙伴的步骤或更新所述建立的可以协作的用户终端信 息。
11.根据权利要求1或2所述的方法，其特征在于，所述协作用户群组中的用户终端之 间通过蓝牙、红外、无线局域网或其它用户终端之间通讯的其它协议或手段进行通信。
12.根据权利要求1或2所述的方法，其特征在于，所述需要协作的用户终端为用户 接收业务存在错误的用户终端，或者接收的数据包无法满足用户的服务质量QoS的用户终 端，或者用户希望通过协作提高接收质量的用户终端。
13.根据权利要求1或2所述的方法，其特征在于，所述利用该用户协作群组中的其他 用户获取所需业务具体包括所述需要协作的用户终端从可协作的用户终端信息中选择用户终端，并向选出的用户 终端发起要求共享数据请求；收到要求共享数据请求的用户终端将部分或全部所需业务数 据发送给需要协作的用户终端；所述需要协作的用户终端将接收到的部分或全部业务数据，和已接收到的数据联合解 码，获得正确的所需数据；如果所述需要协作的用户终端在接收到协作用户的数据时仍不能正确解码，选择向当 前返回所需业务数据的用户或用户协作群组中的其他用户，重复发起要求共享数据请求；当重复次数超出预设重复次数时，终止本次协作请求。
14.根据权利要求13所述的方法，其特征在于，所述收到要求共享数据请求的用户终 端将部分或全部所需业务数据发送给需要协作的用户终端之前，该方法还包括所述接收要求共享数据请求的用户终端，根据自身建立的可协作的用户终端信息判断 发起请求的用户终端是否是自身允许协作的用户终端，如果是，将部分或全部所需业务数 据发送给需要协作的用户终端；否则，拒绝请求，所述需要协作的用户终端向用户协作群组中的其他用户发起要求共 享数据请求；当所述接收要求共享数据请求的用户终端自身也需要协作时，拒绝请求。
15.根据权利要求1或2所述的方法，其特征在于，所述业务为多播广播业务MBS、或增 强型多播业务E-MBS或多媒体广播组播业务MBMS。
16.一种实现上行的用户协作的方法，其特征在于，该方法包括以下步骤根据用户接收业务属性设置用户协作群组；通过寻找协作伙伴，在用户协作群组中的 各用户终端中建立可以协作的用户终端信息；在用户协作群组中存在需要协作的用户终端时，利用该用户协作群组中的其他用户获 取所需业务；在所述用户终端与业务发射端之间存在重传机制时，该方法还包括所述用户终端通过选择协作用户，建立协作多输入多输出ΜΙΜ0，并通过系统定义的反馈信道或用户专用上 行信道建立上行协作。
17.根据权利要求16所述的方法，其特征在于，所述建立上行协作具体包括请求建立上行协作的所述用户终端，将系统分配给自身的上行资源配置信息发送给被 请求建立上行协作的用户终端；被请求建立上行协作的用户终端根据自身上行资源的占用 情况，在自身剩余的上行资源能够满足接收到的资源要求时，向请求建立上行协作的用户 终端回复满足协作要求；如果满足协作条件，则请求建立上行协作的用户终端与被请求建立上行协作的用户终 端之间进行上行协作协商，请求建立上行协作的用户终端将需协作的用户数据发送给被请 求建立上行协作的用户终端，并按照协商好的协作方式进行上行协作；如果不满足协作条件，被请求建立上行协作的用户终端回复不满足协作条件，请求建 立上行协作的用户终端从可以协作的用户终端信息中，重新选择被请求建立上行协作的用 户终端并重新发起上行协作请求。
18.根据权利要求17所述的方法，其特征在于，所述上行协作协商的协作方式为采用 空频编码/空时编码SFBC/STBC方式，或者循环延时CDD方式，或者预编码方式，或者天线 波束赋形技术。
19.一种实现用户间协作的系统，该系统包括对小区中的所有用户或一组用户实现业 务链接的基站，其特征在于，该系统还包括两个或两个以上用户终端，其中，用户终端，用于在根据用户接收业务属性设置用户协作群组中，通过寻找协作伙伴，建 立可以协作的用户终端信息，在存在需要协作时，利用该用户终端所在协作群组中的其他 用户获取所需业务。
20.根据权利要求19所述的系统，其特征在于，当所述用户协作群组中的用户终端与 基站之间存在上行反馈信道时，所述用户终端还用于，通过在用户协作群组中选择协作用户，建立协作ΜΙΜ0，并通过系 统定义的反馈信道或用户专用反馈信道进行上行协作。
21.根据权利要求19或20所述的系统，其特征在于，所述用户协作群组中的用户终端 之间通过蓝牙、红外、无线局域网或其它用户终端之间通讯的其它协议、或其它通信方式进 行通信。
22.根据权利要求19或20所述的系统，其特征在于，所述业务为多播广播业务MBS、或 增强型多播业务E-MBS或多媒体广播组播业务MBMS。
全文摘要
本发明提供了一种实现用户间协作的方法及系统，针对接收相同业务的用户设置用户协作群组，并通过寻找协作伙伴，在用户协作群组中的各用户终端中建立可以协作的用户终端信息；在用户协作群组中存在需要协作的用户终端时，利用该用户协作群组中的其他用户获取所需业务。通过本发明用户间的协作，保证了用户正确接收业务，提高了用户的QoS。在用户终端与业务发射端(如基站)之间存在上行反馈信道时，可以通过选择协作用户，建立协作多输入多输出(MIMO)，并通过系统定义的反馈信道或用户专用反馈信道进行上行协作，提高了上行的可靠性，进而保证了系统的整体性能，提高了用户的感受。
文档编号H04L1/06GK101882979SQ200910083188
公开日2010年11月10日 申请日期2009年5月5日 优先权日2009年5月5日
发明者王文焕 申请人:中兴通讯股份有限公司