CN103874137A - 一种上行多点协作传输的接收方法及系统 - Google Patents
一种上行多点协作传输的接收方法及系统 Download PDFInfo
- Publication number
- CN103874137A CN103874137A CN201210536176.XA CN201210536176A CN103874137A CN 103874137 A CN103874137 A CN 103874137A CN 201210536176 A CN201210536176 A CN 201210536176A CN 103874137 A CN103874137 A CN 103874137A
- Authority
- CN
- China
- Prior art keywords
- user data
- serving cell
- base station
- main serving
- data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Mobile Radio Communication Systems (AREA)
Abstract
本申请公开了一种上行多点协作传输的接收方法，包括：A、主服务小区接收用户设备发送的上行信号，并对接收的用户数据进行基带处理；B、主服务小区判断接收的用户数据是否正确，若是，执行步骤C，否则执行步骤D；C、主服务小区将用户数据接收正确的消息通知协作小区，各协作小区清除本次接收数据，本次接收的用户数据处理过程结束，退出本流程；D、主服务小区将用户数据接收错误的信息通知各协作小区；E、各协作小区分别对用户的接收数据进行基带处理，协作小区将处理后的数据传给主服务小区；F、主服务小区接收到来自协作小区的数据后，与主服务小区处理后的数据进行合并处理。本申请还提供了一种上行多点协作传输的接收系统。通过应用本申请技术方案，能够有效减少不同小区之间的链路开销，降低主服务小区的处理负荷。
Description
技术领域
本申请涉及移动通信技术领域，尤其涉及一种上行多点协作传输的接收方法及系统。
背景技术
以正交频分复用（OFDM）技术为代表的LTE系统大大提高了无线通信系统的峰值速率和峰值频谱效率。但是小区边缘的用户由于处于整个小区的边界，其服务质量和吞吐量受到了严重影响。为了解决此问题，进一步提升边缘用户的服务质量和吞吐量，引入了多点协作传输（CoMP）技术。
CoMP技术的主要思想就是位于小区边缘的用户可以通过与多个小区进行信号的传输（接收和发送），对信号进行协同处理。在下行CoMP系统中，多个小区可以为边缘用户协作发送信号，提高下行传输性能；对于上行CoMP系统，多个小区可以联合接收处理边缘用户的上行信号，以提高边缘用户的吞吐量。
在上行CoMP系统中，所有协作小区将各自接收的边缘用户的原始天线数据传输给主服务小区，主服务小区把所有的原始天线数据统一进行联合基带处理。这种将原始天线数据进行合并的处理方法可以有效地利用多个接收信号，获得分集增益和天线阵列增益。如图1所示，假设用户设备（UE）处于小区边缘位置，小区1是UE的主服务小区，小区2和小区3为UE的协作服务小区。UE的上行发送信号通过无线链路传输，可以分别被小区1、小区2和小区3接收到，三个小区通过多点协作方式同时为UE服务。
这种方案对于提升边缘用户的性能在理论上可以获得最好的增益，但是随着各小区天线数量的增加，各协作小区的链路传输开销会随之增大；同时，随着协作小区数量和各小区天线数量的增加，主服务小区的基带处理会急剧升高，严重影响整个网络的处理能力和整体性能。
发明内容
本申请提供了一种上行多点协作传输的接收方法及系统，能够有效减少不同小区之间的链路开销，降低主服务小区的处理负荷。
本申请实施例提供的一种上行多点协作传输的接收方法，包括：
A、主服务小区接收用户设备发送的上行信号，并对接收的用户数据进行基带处理；
B、主服务小区判断接收的用户数据是否正确，若是，执行步骤C，否则执行步骤D；
C、主服务小区将用户数据接收正确的消息通知协作小区，各协作小区清除本次接收的用户数据，本次接收的用户数据处理过程结束，退出本流程；
D、主服务小区将用户数据接收错误的信息通知各协作小区；
E、各协作小区分别对接收的用户数据进行基带处理，协作小区将处理后的用户数据传给主服务小区；
F、主服务小区接收到来自协作小区的用户数据后，与主服务小区处理后的用户数据进行合并处理。
较佳地，所述步骤F之后，进一步包括：
G、主服务小区根据合并处理得到用户数据判断是否接收正确，若是，本次接收的用户数据处理过程结束，结束本流程，否则执行步骤H；
H、主服务小区向用户设备发送重传指令，要求进行数据重传。
较佳地，步骤F之前，进一步包括：
主服务小区接收到来自协作小区的数据后，判断其中是否有正确的解调结果，若是，主服务小区将正确的解调结果作为接收的用户数据，本次接收的用户数据处理过程结束，退出本流程；否则执行步骤F。
较佳地，判断其中是否有正确的解调结果的结果为是，则进一步包括：
主服务小区通知尚未发送用户数据的协作小区无需继续处理，收到所述通知的协作小区清除接收的用户数据。
较佳地，所述主服务小区判断接收的用户数据是否正确为：主服务小区根据基带处理得到的用户校验信息CRC判断是否接收正确。
本申请实施例还提供了一种上行多点协作传输的接收系统，包括一个主服务小区基站和至少一个协作小区基站，
所述主服务小区基站包括：
信号处理单元，用于对主服务小区基站接收的用户设备发送的上行信号中的用户数据进行基带处理；
校验单元，用于判断所述信号处理单元处理后的用户数据是否正确；
通知单元，用于将所述校验单元的判断结果通知协作小区基站；
合并处理单元，用于将主服务小区基站接收到的来自协作小区基站的用户数据与主服务小区基站处理后的数据进行合并处理；
所述协作小区基站包括：
通知接收单元，用接收来自主服务小区基站的通知；
协作处理单元，用于接收用户设备发送的上行信号，若所述通知接收单元收到来自主服务小区基站的用户数据接收正确的消息，则清除本次接收数据，结束本次接收的用户数据处理过程；若所述通知接收单元收到来自主服务小区基站的用户数据接收错误的消息，则对接收的用户数据进行基带处理，将处理后的数据传给主服务小区。
较佳地，所述主服务小区基站进一步包括重传指令单元；
所述主服务小区基站的校验单元进一步用于根据所述合并处理单元进行合并处理得到用户数据判断是否接收正确，若是，本次接收的用户数据处理过程结束，结束本流程，否则通知重传指令单元；
所述重传指令单元在收到来自校验单元的通知后，向用户设备发送重传指令，要求进行数据重传。
较佳地，所述主服务小区基站的校验单元进一步用于在主服务小区基站接收到来自协作小区的数据后，判断其中是否有正确的解调结果，若是，将正确的解调结果作为接收的用户数据，本次接收的用户数据处理过程结束。
较佳地，所述校验单元判断其中是否有正确的解调结果的结果为是，则所述通知单元通知尚未发送数据的协作小区无需继续处理，收到所述通知的协作小区基站的协作处理单元清除接收的用户数据。
较佳地，所述主服务小区的校验单元根据基带处理得到的用户校验信息CRC判断是否接收正确。
从以上技术方案可以看出，主服务小区接收用户设备发送的上行信号，并对接收的用户数据进行基带处理；主服务小区判断接收的用户数据是否正确，若否，主服务小区将用户数据接收错误的信息通知各协作小区；各协作小区分别对用户的接收数据进行基带处理，协作小区将处理后的数据传给主服务小区；主服务小区接收到来自协作小区的数据后，与主服务小区处理后的数据进行合并处理。可见，通过协调判决机制，只有在主服务小区单独解调数据出错的条件下协作小区才向主服务小区传输解调后的数据，由主服务小区完成数据合并处理。该方案合理利用了各小区的处理资源，有效减少了不同小区之间的链路开销，降低了主服务小区的处理负荷。
附图说明
图1为上行多点协作传输系统模型示意图；
图2为本申请实施例一提出的上行多点协作传输的接收方法的处理流程图；
图3为本申请实施例二提出的上行多点协作传输的接收方法的处理流程图；
图4为本申请实施例三提出的上行多点协作传输的接收方法的处理流程图。
具体实施方式
本申请提出了一种易于实现的上行多点协作接收处理方案，主服务小区接收用户设备发送的上行信号，并对接收的用户数据进行基带处理；主服务小区判断接收的用户数据是否正确，若否，主服务小区将用户数据接收错误的信息通知各协作小区；各协作小区分别对用户的接收数据进行基带处理，协作小区将处理后的数据传给主服务小区；主服务小区接收到来自协作小区的数据后，与主服务小区处理后的数据进行合并处理。可见，通过协调判决机制，只有在主服务小区单独解调数据出错的条件下协作小区才向主服务小区传输解调后的数据，由主服务小区完成数据合并处理。所述解调后的数据可以是比特级数据、符号级数据或其他级别的数据。该方案合理利用了各小区的处理资源，有效减少了不同小区之间的链路开销，降低了主服务小区的处理负荷。
为使本申请技术方案的技术原理、特点以及技术效果更加清楚，以下结合具体实施例对本申请技术方案进行详细阐述。
本申请实施例一提出的上行多点协作传输的接收方法的处理流程如图2所示，包括如下步骤：
步骤201：主服务小区接收UE发送的上行信号，并对接收的用户数据进行基带处理。
步骤202：主服务小区根据基带处理得到的用户校验信息（CRC）判断是否接收正确，若是，执行步骤203，否则执行步骤204。
步骤203：主服务小区将CRC解调正确信息通知协作小区，各协作小区清除本次接收数据，本次接收的用户数据处理过程结束，退出本流程。
步骤204：主服务小区将CRC解调错误信息通知各协作小区。
步骤205：各协作小区分别对用户的接收数据进行基带处理，协作小区将处理后的数据传给主服务小区。
步骤206：主服务小区接收到来自协作小区的数据后，与主服务小区处理后的数据进行合并处理。
由于合并处理后并不能保证数据一定接收正确，如果仍然CRC解调错误，则可以要求UE重新发送数据。本申请实施例二提出上行多点协作传输的接收方法的处理流程在实施例一的基础上，增加了对合并处理后的CRC进行判断，在校验错误的情况下要求UE重发数据的处理步骤。实施例二的流程如图3所示，包括：
步骤301：主服务小区接收UE发送的上行信号，并对接收的用户数据进行基带处理。
步骤302：主服务小区根据处理得到的用户校验信息（CRC）判断是否接收正确，若是，执行步骤303，否则执行步骤304。
步骤303：主服务小区将CRC正确信息通知协作小区，各协作小区清除本次接收数据，本次接收的用户数据处理过程结束，退出本流程。
步骤304：主服务小区将CRC解调错误信息通知各协作小区。
步骤305：各协作小区分别对用户的接收数据进行基带处理，将处理后的数据传给主服务小区。
步骤306：主服务小区接收到来自协作小区的数据后，与主服务小区处理后的数据进行合并处理。
步骤307：主服务小区根据合并处理得到的用户校验信息（CRC）判断是否接收正确，若是，本次接收的用户数据处理过程结束，结束本流程，否则执行步骤308。
步骤308：主服务小区向UE发送重传指令，要求进行数据重传。
在实施例一或实施例二的处理过程中，如果主服务小区解调错误，多个协作小区均对接收数据进行解调处理，实际上如果有任何一个协作小区解调正确，只要将该协作小区解调得到的数据发送给主服务小区即可实现数据的正确接收。基于此种考虑，本申请实施例三提出了上行多点协作传输的接收方法的处理流程，如图4所示，包括：
步骤401：主服务小区接收UE发送的上行信号，并对接收的用户数据进行基带处理。
步骤402：主服务小区根据处理得到的用户校验信息（CRC）判断是否接收正确，若是，执行步骤403，否则执行步骤404。
步骤403：主服务小区将CRC正确信息通知协作小区，各协作小区清除本次接收数据，本次接收的用户数据处理过程结束，退出本流程。
步骤404：主服务小区将CRC解调错误信息通知各协作小区。
步骤405：各协作小区分别对用户的接收数据进行基带处理，协作小区将处理后的数据传给主服务小区。
步骤406：主服务小区接收到来自协作小区的数据后，判断其中是否有正确的解调结果，若是，执行步骤407，否则执行步骤408。
步骤407：主服务小区将正确的解调结果作为接收的用户数据，本次接收的用户数据处理过程结束，退出本流程。
步骤408：主服务小区将来自协作小区的数据与主服务小区处理后的数据进行合并处理。
出于进一步节约资源的考虑，步骤407可以进一步包括：主服务小区通知尚未发送数据的协作小区无需继续处理，收到所述通知的协作小区清除接收数据。
类似实施例二，步骤408之后还可以进一步包括：
步骤409：主服务小区根据合并处理得到的用户校验信息（CRC）判断是否接收正确，若是，本次接收的用户数据处理过程结束，结束本流程，否则执行步骤410。
步骤410：主服务小区向UE发送重传指令，要求进行数据重传。
本申请实施例四提供了一种上行多点协作传输的接收系统，包括一个主服务小区基站和至少一个协作小区基站，
所述主服务小区基站包括：
信号处理单元，用于对主服务小区基站接收的用户设备发送的上行信号中的用户数据进行基带处理；
校验单元，用于判断所述信号处理单元处理后的用户数据是否正确；
通知单元，用于将所述校验单元的判断结果通知协作小区基站；
合并处理单元，用于将主服务小区基站接收到的来自协作小区基站的用户数据与主服务小区基站处理后的数据进行合并处理；
所述协作小区基站包括：
通知接收单元，用接收来自主服务小区基站的通知；
协作处理单元，用于接收用户设备发送的上行信号，若所述通知接收单元收到来自主服务小区基站的用户数据接收正确的消息，则清除本次接收数据，结束本次接收的用户数据处理过程；若所述通知接收单元收到来自主服务小区基站的用户数据接收错误的消息，则对接收的用户数据进行基带处理，将处理后的数据传给主服务小区。
较佳地，所述主服务小区基站进一步包括重传指令单元；
所述主服务小区基站的校验单元进一步用于根据所述合并处理单元进行合并处理得到用户数据判断是否接收正确，若是，本次接收的用户数据处理过程结束，结束本流程，否则通知重传指令单元；
所述重传指令单元在收到来自校验单元的通知后，向用户设备发送重传指令，要求进行数据重传。
较佳地，所述主服务小区基站的校验单元进一步用于在主服务小区基站接收到来自协作小区的数据后，判断其中是否有正确的解调结果，若是，将正确的解调结果作为接收的用户数据，本次接收的用户数据处理过程结束。
较佳地，所述校验单元判断其中是否有正确的解调结果的结果为是，则所述通知单元通知尚未发送数据的协作小区无需继续处理，收到所述通知的协作小区基站的协作处理单元清除接收的用户数据。
较佳地，所述主服务小区的校验单元根据基带处理得到的用户校验信息CRC判断是否接收正确。
以上所述仅为本申请的较佳实施例而已，并不用以限制本申请的保护范围，凡在本申请技术方案的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。
Claims (10)
1.一种上行多点协作传输的接收方法，其特征在于，包括：
A、主服务小区接收用户设备发送的上行信号，并对接收的用户数据进行基带处理；
B、主服务小区判断接收的用户数据是否正确，若是，执行步骤C，否则执行步骤D；
C、主服务小区将用户数据接收正确的消息通知协作小区，各协作小区清除本次接收的用户数据，本次接收的用户数据处理过程结束，退出本流程；
D、主服务小区将用户数据接收错误的信息通知各协作小区；
E、各协作小区分别对接收的用户数据进行基带处理，协作小区将处理后的用户数据传给主服务小区；
F、主服务小区接收到来自协作小区的用户数据后，与主服务小区处理后的用户数据进行合并处理。
2.根据权利要求1所述的方法，其特征在于，所述步骤F之后，进一步包括：
G、主服务小区根据合并处理得到用户数据判断是否接收正确，若是，本次接收的用户数据处理过程结束，结束本流程，否则执行步骤H；
H、主服务小区向用户设备发送重传指令，要求进行数据重传。
3.根据权利要求1或2所述的方法，其特征在于，步骤F之前，进一步包括：
主服务小区接收到来自协作小区的数据后，判断其中是否有正确的解调结果，若是，主服务小区将正确的解调结果作为接收的用户数据，本次接收的用户数据处理过程结束，退出本流程；否则执行步骤F。
4.根据权利要求3所述的方法，其特征在于，判断其中是否有正确的解调结果的结果为是，则进一步包括：
主服务小区通知尚未发送用户数据的协作小区无需继续处理，收到所述通知的协作小区清除接收的用户数据。
5.根据权利要求1或2所述的方法，其特征在于，所述主服务小区判断接收的用户数据是否正确为：主服务小区根据基带处理得到的用户校验信息CRC判断是否接收正确。
6.一种上行多点协作传输的接收系统，包括一个主服务小区基站和至少一个协作小区基站，其特征在于，
所述主服务小区基站包括：
信号处理单元，用于对主服务小区基站接收的用户设备发送的上行信号中的用户数据进行基带处理；
校验单元，用于判断所述信号处理单元处理后的用户数据是否正确；
通知单元，用于将所述校验单元的判断结果通知协作小区基站；
合并处理单元，用于将主服务小区基站接收到的来自协作小区基站的用户数据与主服务小区基站处理后的数据进行合并处理；
所述协作小区基站包括：
通知接收单元，用接收来自主服务小区基站的通知；
协作处理单元，用于接收用户设备发送的上行信号，若所述通知接收单元收到来自主服务小区基站的用户数据接收正确的消息，则清除本次接收数据，结束本次接收的用户数据处理过程；若所述通知接收单元收到来自主服务小区基站的用户数据接收错误的消息，则对接收的用户数据进行基带处理，将处理后的数据传给主服务小区。
7.根据权利要求6所述的系统，其特征在于，所述主服务小区基站进一步包括重传指令单元；
所述主服务小区基站的校验单元进一步用于根据所述合并处理单元进行合并处理得到用户数据判断是否接收正确，若是，本次接收的用户数据处理过程结束，结束本流程，否则通知重传指令单元；
所述重传指令单元在收到来自校验单元的通知后，向用户设备发送重传指令，要求进行数据重传。
8.根据权利要求6或7所述的系统，其特征在于，所述主服务小区基站的校验单元进一步用于在主服务小区基站接收到来自协作小区的数据后，判断其中是否有正确的解调结果，若是，将正确的解调结果作为接收的用户数据，本次接收的用户数据处理过程结束。
9.根据权利要求8所述的系统，其特征在于，所述校验单元判断其中是否有正确的解调结果的结果为是，则所述通知单元通知尚未发送数据的协作小区无需继续处理，收到所述通知的协作小区基站的协作处理单元清除接收的用户数据。
10.根据权利要求6或7所述的系统，其特征在于，所述主服务小区的校验单元根据基带处理得到的用户校验信息CRC判断是否接收正确。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201210536176.XA CN103874137A (zh) | 2012-12-12 | 2012-12-12 | 一种上行多点协作传输的接收方法及系统 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201210536176.XA CN103874137A (zh) | 2012-12-12 | 2012-12-12 | 一种上行多点协作传输的接收方法及系统 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN103874137A true CN103874137A (zh) | 2014-06-18 |
Family
ID=50912177
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201210536176.XA Pending CN103874137A (zh) | 2012-12-12 | 2012-12-12 | 一种上行多点协作传输的接收方法及系统 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN103874137A (zh) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108206726A (zh) * | 2016-12-20 | 2018-06-26 | 中兴通讯股份有限公司 | 一种合并小区的数据处理方法、装置及系统 |
| CN110612683A (zh) * | 2017-05-31 | 2019-12-24 | 华为技术有限公司 | 一种上行数据的协作接收方法及网络设备 |
| WO2022056691A1 (zh) * | 2020-09-15 | 2022-03-24 | Oppo广东移动通信有限公司 | 联合传输方法、终端设备、目标网络设备和协作网络设备 |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101640901A (zh) * | 2009-04-29 | 2010-02-03 | 北京邮电大学 | 基于上行协作多点的数据合并接收方法 |
| CN101841495A (zh) * | 2009-03-16 | 2010-09-22 | 上海贝尔股份有限公司 | 一种用于上行协作多点传输用户数据的方法及装置 |
-
2012
- 2012-12-12 CN CN201210536176.XA patent/CN103874137A/zh active Pending
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101841495A (zh) * | 2009-03-16 | 2010-09-22 | 上海贝尔股份有限公司 | 一种用于上行协作多点传输用户数据的方法及装置 |
| CN101640901A (zh) * | 2009-04-29 | 2010-02-03 | 北京邮电大学 | 基于上行协作多点的数据合并接收方法 |
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108206726A (zh) * | 2016-12-20 | 2018-06-26 | 中兴通讯股份有限公司 | 一种合并小区的数据处理方法、装置及系统 |
| CN108206726B (zh) * | 2016-12-20 | 2022-07-19 | 中兴通讯股份有限公司 | 一种合并小区的数据处理方法、装置及系统 |
| CN110612683A (zh) * | 2017-05-31 | 2019-12-24 | 华为技术有限公司 | 一种上行数据的协作接收方法及网络设备 |
| CN110612683B (zh) * | 2017-05-31 | 2021-02-12 | 华为技术有限公司 | 一种上行数据的协作接收方法及网络设备 |
| WO2022056691A1 (zh) * | 2020-09-15 | 2022-03-24 | Oppo广东移动通信有限公司 | 联合传输方法、终端设备、目标网络设备和协作网络设备 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN106230488B (zh) | 用于自发合并的系统和方法 | |
| CN102197617B (zh) | 使用了协作harq通信方式的无线基站装置、无线终端装置、无线通信系统以及无线通信方法 | |
| CN101924609B (zh) | 协作多点传输中上行数据的处理方法及相关装置 | |
| CN101841495B (zh) | 一种用于上行协作多点传输用户数据的方法及装置 | |
| CN110476383A (zh) | 针对基于码块群的传输的反馈 | |
| CN110476380A (zh) | 用于基于码块群的传输的多harq方法和装置 | |
| CN101795169A (zh) | 中继协助通信系统及其方法 | |
| CN108370294A (zh) | 用于harq重传跳过的技术 | |
| CN101965741A (zh) | 用于协作无线通信的方法和设备 | |
| CN101640901A (zh) | 基于上行协作多点的数据合并接收方法 | |
| CN104756425B (zh) | 用于协调多点接收的分布式v-mimo处理 | |
| CN103858455A (zh) | 用于通信系统中多点传输的系统和方法 | |
| CN109314609A (zh) | 用于具有极性码的混合自动重复请求(harq)机制的技术 | |
| CN109196933A (zh) | 无线电网络节点、无线设备以及其中执行的方法 | |
| CN103825687A (zh) | 用于蜂窝网络下的设备到设备通信的信令传输方法 | |
| CN103974430A (zh) | 一种数据传输方法及装置 | |
| CN109392161A (zh) | 处理弹性双工的装置及方法 | |
| CN103874137A (zh) | 一种上行多点协作传输的接收方法及系统 | |
| CN107396452A (zh) | 一种无线通信中的方法和装置 | |
| CN101938300B (zh) | 基于多点协作的数据传输方法及装置 | |
| CN102137517B (zh) | 一种实现多点协作发送/接收数据的方法及系统 | |
| CN103379649B (zh) | 数据合并方法及装置 | |
| CN115412226A (zh) | 一种被用于无线通信的节点中的方法和装置 | |
| CN103313392B (zh) | 处理控制信道的方法及其通讯装置 | |
| WO2013125767A1 (ko) | 무선 접속 시스템에서 데이터 송수신 방법 및 이를 위한 장치 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| RJ01 | Rejection of invention patent application after publication | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20140618 |