CN108566264B - 触发无线链路控制层确认模式状态报告的方法及通信系统 - Google Patents
触发无线链路控制层确认模式状态报告的方法及通信系统 Download PDFInfo
- Publication number
- CN108566264B CN108566264B CN201810330279.8A CN201810330279A CN108566264B CN 108566264 B CN108566264 B CN 108566264B CN 201810330279 A CN201810330279 A CN 201810330279A CN 108566264 B CN108566264 B CN 108566264B
- Authority
- CN
- China
- Prior art keywords
- overtime
- status report
- congestion
- receiving
- rlc
- 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.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/1607—Details of the supervisory signal
- H04L1/1671—Details of the supervisory signal the supervisory signal being transmitted together with control information
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1867—Arrangements specially adapted for the transmitter end
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
一种触发无线链路控制层确认模式状态报告的方法及通信系统,当信道传输质量不佳的情况下,根据接收端的接收情况采取针对性的状态报告触发措施。当下层媒体接入控制层上报发送端混合自动重传达最大次数之后,主动上报无线链路控制层以触发状态报告回复,更进一步的,通过接收窗口的拥塞程度判定,自适应调整状态禁止定时器,进一步提高状态报告实时性,以便发送及接收窗口能够快速更新。本发明技术方案能够高效、合理的提高状态报告的实时性,很好的避免由于信道传输质量不佳状态报告回复不及时所带来的空口数据传输时延增大及发送端负荷较大的问题,进一步提升用户体验。
Description
技术领域
本发明涉及移动通信技术领域,尤其是涉及一种触发无线链路控制层确认模式(RLC AM)状态报告的方法及相应通信系统。
背景技术
RLC(Radio Link Control,无线链路控制)协议层在LTE的无线接口协议栈中,是层2(L2)的一个子层,位于MAC(Media Access Control,媒体接入控制)层之上,PDCP(Packet Data Convergence Protocol,包数据汇聚协议)层之下。RLC协议层的功能包括链接控制、用户数据传输(包括分段、级联、重分段、重排序、重组等)、纠错、协议错误检测和修复等,为用户面和控制面数据提供分段和重传业务。
每个RLC协议实体由RRC(Radio Resource Control,无线资源控制)层配置并以三种数据传输模式进行工作,分别为:透传模式(TM,Transparent Mode)、非确认模式(UM,Unacknowledged Mode)和确认模式(AM,Acknowledged Mode)。确认模式中的ARQ(Automatic Repeat Request,自动重传请求)是通过接收端向发送端反馈状态报告(Status Report),发送端根据收到的Status Report中的ACK_SN(状态报告截止的报文编号)和NACK_SN(ACK_SN之前未收到报文的报文编号)来判定哪些PDU(Protocol Data Unit,协议数据单元)已经被接收端确认收到,哪些PDU或PDU分片需要重传,从而保证数据传输的可靠性。
36.322协议中,目前对确认模式下状态报告的触发过程涉及到了两个定时器,都用在RLC的数据传输接收端。首先是重排序定时器t-Reordering,t-Reordering用于检测底层数据的丢失情况,超时后向发送端发送状态报告。其次是状态报告禁止定时器t-StatusProhibit,t-StatusProhibit用于限制状态报告的发送频率,即两次状态报告的发送时刻需要满足一定的时间间隔,这个间隔就是该定时器时长。目前状态报告的触发有两种方式:1、RLC发送端通过轮询的方式触发;2、RLC接收端检测到PDU接收失败(重排序定时器超时)。这里主要介绍一下和本发明相关的第二种方式。首先,RLC接收端若检测到报文不是按照顺序到达的,就会立即启动重排序定时器t-Reordering,t_reordering定时器超时会触发VR(MS)(Maximum STATUS transmit state variable,最大Status状态报告反馈变量)的更新和状态报告的发送,VR(MS)在数据接收窗口中用于标识构造状态报告的截止位置,即前述ACK_SN的取值,状态报告的发送必须在VR(MS)的更新之后触发。其次,状态报告的触发并不是毫无限制的,需要满足一定的发送间隔。若t-StatusProhibit(Statusprohibit timer,状态报告禁止定时器)没有运行,则在MAC层指示的第一个传输机会到来时,构造Status Report并向底层发送;否则,在t-StatusProhibit定时器超时之后的第一个MAC层指示的传输机会到来时,构造StatusReport并向底层发送。当一个状态报告已经向底层发送,RLC AM实体接收端会启动t-StatusProhibit定时器。
可以知道,确认模式下报文的传输需要通过状态报告来进行确认。而状态报告的触发方式之一就是重排序定时器t-Reordering超时,t-Reordering实质上就是对由于底层HARQ(Hybrid Automatic Repeat Request,混合自动重传请求)重传导致的乱序包进行排序过程的一个定时器,如果超时了,就认为底层HARQ已经无法解决问题了,这个时候对于这部分没有排好序的包(小于VR(MS))就可以通过发送状态报告的方式触发RLC发送端进行ARQ重传。基于协议的这一设计,在实际现网应用过程中,t-Reordering配置时长通常是大于底层HARQ最大重传所需要消耗的时间的,于是就存在了一个时间差,当发送端底层达到HARQ最大重传仍没有成功的时候,接收端RLC层并不会立即触发状态报告回复而仍然等待HARQ重传直至t-Reordering超时。
针对高可靠性业务传输时,采用有反馈确认的双向链路传输需要正向和反向链路都具有较小的时延和可靠的传输性能。在高速率业务场景下,正向业务数据PDU传输和反向状态报告PDU传输的丢失都会导致RLC的ARQ重传,进而容易导致发送窗口满并影响业务速率。而反向状态报告回复的时延同样也会导致发送端发送窗口满无法发送新的PDU,影响业务速率。
现有相关技术中,接收端RLC层检测底层数据丢失情况只能通过t-Reordering超时来进行判断,实时性不佳,无法第一时间做出反馈。同时由于t-StatusProhibit定时器的存在,当信道传输质量不佳时,容易造成窗口因被撑满而停滞的情况,此时可能至少需要等待一个状态禁止定时器周期才能解除窗口的停滞状态,从而造成空口数据传输延迟,时延增大,影响用户体验。因此本领域亟待相关解决方案出现。
发明内容
本发明的主要目的在于克服现有技术,本发明提供了一种触发无线链路控制层确认模式状态报告的方法及相应通信系统,通过提高状态报告的实时性,解决由于状态报告回复不及时所引起的空口数据传输时延增大及发送端负荷较大的问题。
本发明所采用的技术方案包括一种触发无线链路控制层确认模式状态报告的方法,执行以下步骤:
1)基站MAC层混合自动重传请求HARQ达最大重传时上报指示到RLC层;
2)基站RLC接收端收到指示立即触发t-Reordering定时器超时判断流程;
3)判断此时t-StatusProhibit是否超时,若超时进入步骤5,否则进入步骤4;
4)判断此时RLC接收端接收窗口状态,若此时接收窗口处于拥塞状态,则进入步骤6,否则进入步骤7;
5)进入t-StatusProhibit超时处理流程,完成状态报告的调度组包并传输下去;
6)窗口拥塞触发的t-StatusProhibit超时处理流程,完成状态报告的调度组包并传输下去;
7)等待t-StatusProhibit超时以触发后续处理流程。
而且,步骤1中,接收端MAC上报发送端HARQ已达最大重传指示给RLC,以此触发t-Reordering定时器超时判断流程,开启状态报告回复。
而且,步骤4中,对于接收端RLC接收窗口进行拥塞状态判别,拥塞度定义如下:
接收窗实时拥塞度=接收窗口缓存量/接收窗口长度接收窗实时拥塞度高于设置的拥塞门限时,判断此时接收窗口处于拥塞状态。
而且,对拥塞门限预设初始值,根据实际的业务及信道场景进行动态调整。
而且,拥塞门限的初始值设置为0.9。
本发明还提供一种通信系统,执行如上所述触发无线链路控制层确认模式状态报告的方法。
对比现有技术,本发明提供了一种AM模式下状态报告的触发方法及相应通信系统,能够较好的提高状态报告的实时性。该系统能够很好的避免信道传输质量不佳情况下,由于状态报告回复不及时所引起的空口数据传输时延增大及发送端负荷较大的问题,进一步提升用户体验。
附图说明
图1为本发明实施例提供的RLC接收端接收窗口拥塞状态判别示意图。
图2为本发明实施例提供的RLC接收端状态报告触发流程示意图。
具体实施方式
以下结合附图和实施例说明本发明技术方案。
现有技术中,状态报告的触发依赖于发送端的轮询或者重排序定时器及状态禁止定时器的超时触发,实时性不佳,在信道传输质量较差时,容易引起发送端拖窗的现象,从而造成时延增大,影响用户体验。
本发明通过接收端上报发送端HARQ最大重传来主动触发状态报告用以提高状态报告的实时性,进一步的,通过接收窗口的拥塞程度判定,自适应调整状态禁止定时器,解决信道质量不佳的情况下由于状态报告回复不及时引发的拖窗问题,进一步提升用户体验。
参见附图2,本发明实施例在接收端提供状态报告触发流程,包含在基站中执行下列步骤:
1)基站MAC层HARQ达最大重传时,上报指示到RLC层;
接收端MAC上报发送端HARQ已达最大重传指示给RLC,以此触发t-Reordering定时器超时判断流程,开启状态报告回复;
2)基站RLC接收端收到该指示,立即触发t-Reordering定时器超时流程,也就是即使实际上t-Reordering定时器未超时,但视同t-Reordering定时器超时;
3)判断此时t-StatusProhibit是否超时,若超时进入步骤5,否则进入步骤4;
协议上规定的只有当t-StatusProhibit超时后才允许进入状态报告反馈流程,目的在于控制状态报告反馈的频率,如果太频繁势必会占用太多空口带宽资源。当t-Reordering定时器超时,t-StatusProhibit可能超时也可能未超时,如果超时马上开始状态报告反馈,如果没有超时,则此时需要进入拥塞度判别,如果处于拥塞状态,那就表示窗口即将撑满,此时即使t-StatusProhibit没有超时,也要进入t-StatusProhibit超时流程(即开始进行状态报告反馈),如果不处于拥塞状态,则继续等待t-StatusProhibit超时,待超时后触发后续的状态报告反馈;
4)判断此时RLC接收端接收窗口状态:若此时接收窗口处于拥塞状态,则进入步骤6,否则进入步骤7;
对于接收端RLC接收窗口进行拥塞状态判别,拥塞度定义如下:
接收窗实时拥塞度=接收窗口缓存量/接收窗口长度
接收窗口可设置一个接收阈值(VR(H)/VR(MR)),作为一项可配参数,在不同的场景及信道环境下可以实现动态配置,减小传输时延,提高传输性能,提升用户传输体验。
若此时VR(H)/VR(MR)达到一定阈值(例如0.8,阈值越接近1表示RLC接收窗口越接近撑满状态,需要通过对VR(R)尽快进行状态反馈来触发VR(R)重传以触发VR(R)更新驱动接收窗口前移。
拥塞门限可根据实际的业务及信道场景进行动态调整,初始值优选设置为0.9。
VR(H)-Highest received state variable,接收到的最高状态变量,表示接收到的最大pdu(协议业务单元)的sn(sequence number,序列号)+1。
VR(MR)-Maximum acceptable receive state variable,最大可接受的状态变量,表示可接收窗口的边界,恒等于VR(R)+Window Size,VR(R)和VR(MR)代表了接收端可接收窗口的上下边界。
实际接收的pdu sn必须在接收窗口边界内,超出边界外的pdu不接收直接丢弃。所以VR(H)一定小于VR(MR)。
最理想的情况下,接收窗口无缓存,即VR(H)=VR(R)+1,所以此时的拥塞度=1/Receving Window Size;
另一种极端,接收窗口缓存被塞满,那么拥塞度就等于1。
当拥塞度达到0.9了,表示窗口即将被占满了,此时要启动快速反馈,尽量驱动窗口前移,避免由于窗口撑满而导致接收停滞,数据传输中断。
参见图1,当接收端底层MAC上报发送端HARQ达最大重传或者接收端自身t-Reordering定时器超时时,对当前的RLC接收窗进行拥塞状态判别,
如果当前处于拥塞状态(即实时拥塞度高于设置的拥塞门限,(接收窗口剩余缓存量/接收窗口长度)大于拥塞门限),即设置当前承载RLC AM接收窗处于拥塞状态,主动触发t-StatusProhibit超时,立即进行状态报告回复,
否则设置当前承载RLC AM接收窗处于非拥塞状态,等待t-StatusProhibit超时以触发后续流程。
5)进入t-StatusProhibit超时处理流程,完成状态报告的调度组包并传输下去;
按标准协议,t-Statusprohibit超时后的处理流程如下:
1.构造Status Report
2.按需重启t-Reorderding tmr
6)窗口拥塞触发的t-StatusProhibit超时处理流程,完成状态报告的调度组包并传输下去;
由于此时是窗口处于拥塞状态触发的t-StatusProhibit超时,所以与正常的超时相比,需要主动停止t-Statusprohibit定时器,流程如下:
1.Stop t-Statusprohibit tmr
2.构造Status Report
3.按需重启t-Reordering tmr
7)等待t-StatusProhibit超时以触发后续处理流程;
具体实施时,可以预先进行接收端RLC设置AM接收窗口拥塞门限。
该流程考虑了正常超时、等待超时以及未超时但是窗口拥塞情况下直接触发的超时,在窗口拥塞的情况下,就不考虑状态报告是否频繁,进行状态回复,尽快推动窗口前移,避免窗口撑满丢包断流。
通过以上步骤实施,能够有效的提高信道传输质量不佳时RLC AM状态报告的实时性,解决由于状态报告回复不及时所引起的空口数据传输时延增大及发送端负荷较大的问题,进一步提升用户体验。
具体实施时,本发明所提供方法可基于软件技术实现自动运行流程,运行该方法的相应通信系统也在本发明保护范围内,本发明不予赘述。
以上内容是结合具体的实施方式对本发明所作的进一步详细说明,不能认定本发明的具体实施只局限于这些说明。对于本发明所属技术领域的普通技术人员来说,在不脱离本发明构思的前提下,还可以做出若干简单推演或替换,都应当视为属于本发明的保护范围。
Claims (6)
1.一种触发无线链路控制层确认模式状态报告的方法,其特征在于,执行以下步骤:
1)基站MAC层混合自动重传请求HARQ达最大重传时上报指示到RLC层;
2)基站RLC接收端收到指示立即触发t-Reordering定时器超时流程,即使实际上t-Reordering定时器未超时,视同t-Reordering定时器超时;
3)判断此时t-StatusProhibit是否超时,若超时进入步骤5,否则进入步骤4;
4)判断此时RLC接收端接收窗口状态,若此时接收窗口处于拥塞状态,则进入步骤6,否则进入步骤7;
5)进入t-StatusProhibit超时处理流程,完成状态报告的调度组包并传输下去;
6)窗口拥塞触发t-StatusProhibit超时处理流程,完成状态报告的调度组包并传输下去;
7)等待t-StatusProhibit超时以触发后续处理流程。
2.根据权利要求1所述触发无线链路控制层确认模式状态报告的方法,其特征在于:步骤1中,接收端MAC上报发送端HARQ已达最大重传指示给RLC,以此触发t-Reordering定时器超时判断流程,开启状态报告回复。
3.根据权利要求1所述触发无线链路控制层确认模式状态报告的方法,其特征在于:步骤4中,对于接收端RLC接收窗口进行拥塞状态判别,拥塞度定义如下:
接收窗实时拥塞度=接收窗口缓存量/接收窗口长度
接收窗实时拥塞度高于设置的拥塞门限时,判断此时接收窗口处于拥塞状态。
4.根据权利要求3所述触发无线链路控制层确认模式状态报告的方法,其特征在于:对拥塞门限预设初始值,根据实际的业务及信道场景进行动态调整。
5.根据权利要求4所述触发无线链路控制层确认模式状态报告的方法,其特征在于:拥塞门限的初始值设置为0.9。
6.一种通信系统,其特征在于:执行如权利要求1至5所述触发无线链路控制层确认模式状态报告的方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201810330279.8A CN108566264B (zh) | 2018-04-13 | 2018-04-13 | 触发无线链路控制层确认模式状态报告的方法及通信系统 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201810330279.8A CN108566264B (zh) | 2018-04-13 | 2018-04-13 | 触发无线链路控制层确认模式状态报告的方法及通信系统 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN108566264A CN108566264A (zh) | 2018-09-21 |
CN108566264B true CN108566264B (zh) | 2021-03-16 |
Family
ID=63534907
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201810330279.8A Active CN108566264B (zh) | 2018-04-13 | 2018-04-13 | 触发无线链路控制层确认模式状态报告的方法及通信系统 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN108566264B (zh) |
Families Citing this family (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111510417A (zh) * | 2019-01-31 | 2020-08-07 | 普天信息技术有限公司 | 无线链路控制协议栈的配置参数调整方法及装置 |
CN112671515B (zh) * | 2020-12-09 | 2022-05-06 | 中国电子科技集团公司第五十四研究所 | 一种无线链路控制层有限重传数据传输方法 |
Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101232493A (zh) * | 2007-01-26 | 2008-07-30 | 中兴通讯股份有限公司 | 无线链路控制层确认模式下pdu尺寸确定方法和装置 |
CN101753277A (zh) * | 2008-12-16 | 2010-06-23 | 中兴通讯股份有限公司 | 无线链路控制层报文状态报告的发送方法 |
CN101989899A (zh) * | 2009-07-31 | 2011-03-23 | 中兴通讯股份有限公司 | 一种无线链路控制层触发状态报告的方法及接收侧装置 |
KR101368499B1 (ko) * | 2008-03-24 | 2014-02-27 | 삼성전자주식회사 | 이동 통신 시스템에서 상태 보고 메시지를 송신하기 위한 장치 및 방법 |
CN106936918A (zh) * | 2017-03-24 | 2017-07-07 | 武汉虹信通信技术有限责任公司 | 用于lte移动通信系统的rlc pdu传输方法 |
CN107659959A (zh) * | 2016-07-25 | 2018-02-02 | 普天信息技术有限公司 | 一种专网无线通信系统中上报接收数据状态的方法 |
EP3111579B1 (en) * | 2014-02-26 | 2018-02-21 | MediaTek Inc. | Method and apparatus for triggering acknowledgement status report in wireless communications system |
CN107801200A (zh) * | 2016-09-06 | 2018-03-13 | 中兴通讯股份有限公司 | 状态报告的发送方法及装置 |
-
2018
- 2018-04-13 CN CN201810330279.8A patent/CN108566264B/zh active Active
Patent Citations (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101232493A (zh) * | 2007-01-26 | 2008-07-30 | 中兴通讯股份有限公司 | 无线链路控制层确认模式下pdu尺寸确定方法和装置 |
KR101368499B1 (ko) * | 2008-03-24 | 2014-02-27 | 삼성전자주식회사 | 이동 통신 시스템에서 상태 보고 메시지를 송신하기 위한 장치 및 방법 |
CN101753277A (zh) * | 2008-12-16 | 2010-06-23 | 中兴通讯股份有限公司 | 无线链路控制层报文状态报告的发送方法 |
WO2010069206A1 (zh) * | 2008-12-16 | 2010-06-24 | 中兴通讯股份有限公司 | 无线链路控制层报文状态报告的发送方法及系统 |
CN101989899A (zh) * | 2009-07-31 | 2011-03-23 | 中兴通讯股份有限公司 | 一种无线链路控制层触发状态报告的方法及接收侧装置 |
EP3111579B1 (en) * | 2014-02-26 | 2018-02-21 | MediaTek Inc. | Method and apparatus for triggering acknowledgement status report in wireless communications system |
CN107659959A (zh) * | 2016-07-25 | 2018-02-02 | 普天信息技术有限公司 | 一种专网无线通信系统中上报接收数据状态的方法 |
CN107801200A (zh) * | 2016-09-06 | 2018-03-13 | 中兴通讯股份有限公司 | 状态报告的发送方法及装置 |
CN106936918A (zh) * | 2017-03-24 | 2017-07-07 | 武汉虹信通信技术有限责任公司 | 用于lte移动通信系统的rlc pdu传输方法 |
Also Published As
Publication number | Publication date |
---|---|
CN108566264A (zh) | 2018-09-21 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7870259B2 (en) | Method and transmitter for an efficient packet data transfer in a transmission protocol with repeat requests | |
JP3908693B2 (ja) | 移動通信システムにおけるデータ再伝送装置及び方法 | |
US11039328B2 (en) | Technique for monitoring a radio link control (RLC) | |
CA2615915C (en) | System for efficient recovery of node-b buffered data following mac layer reset | |
US8050248B2 (en) | Retransmission in wireless communication systems | |
CN101483505B (zh) | 一种服务数据单元丢弃方法 | |
US8737306B2 (en) | Method for triggering status reports and apparatus thereof | |
US20160150433A1 (en) | Polling and Reporting Mechanism | |
EP2086148A2 (en) | Method for sending status information in mobile telecommunications system and receiver of mobile telecommunications | |
EP2158700B1 (en) | Method for enhancing of controlling radio resources and transmitting status report in mobile telecommunications system and receiver of mobile telecommunications system | |
EP1876747A1 (en) | Method and apparatus for handling transmission errors in a wireless communications system | |
US10050825B2 (en) | Method and equipment for throughput recovery during resumption from outage scenarios | |
AU2009209739A1 (en) | Method for sending status information in mobile telecommunications system and receiver of mobile telecommunications | |
CN102868504A (zh) | 一种发送状态报告的方法和rlc接收实体 | |
US8964652B2 (en) | Method for enhancing of controlling radio resources, method for transmitting status report, and receiver in mobile communication system | |
CN108566264B (zh) | 触发无线链路控制层确认模式状态报告的方法及通信系统 | |
WO2011012005A1 (zh) | 一种无线链路控制层触发状态报告的方法及接收侧装置 | |
WO2011001469A1 (ja) | 無線通信制御方法および無線通信装置 | |
EP2818003B1 (en) | Method and base station for controlling wireless communication of data | |
AU2009245823B2 (en) | System for efficient recovery of node-b buffered data following Mac layer reset | |
KR20100060853A (ko) | 무선 링크 제어 프로토콜에서의 상태 보고 방법 및 시스템 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
TA01 | Transfer of patent application right |
Effective date of registration: 20201027 Address after: 430205 No.1 tanhu 2nd Road, Canglong Island, Jiangxia Economic Development Zone, Wuhan City, Hubei Province Applicant after: Wuhan Hongxin Technology Development Co.,Ltd. Address before: 430073 Hubei province Wuhan Dongxin East Lake high tech Development Zone, Road No. 5 Applicant before: Wuhan Hongxin Telecommunication Technologies Co.,Ltd. |
|
TA01 | Transfer of patent application right | ||
GR01 | Patent grant | ||
GR01 | Patent grant |