CN108259144A - 一种信息的传输方法、终端和网络设备 - Google Patents

Abstract

本发明实施例提供了一种传输信息的方法、终端及网络设备，该传输方法用于在时分双工TDD通信系统中通过多个子帧传输信息,该多个子帧包括第一子帧，该第一子帧包括第一业务信道和第一上行请求信道，所述传输方法包括：该网络设备通过该第一业务信道与该终端传输数据；该网络设备通过该第一上行请求信道，接收该终端的上报信息，该上报信息为第二业务的数据传输请求、第三业务的数据和预设的紧急指令的反馈消息中的至少一种，所述第二业务和所述第三业务为预设的紧急业务。该方法能够减小上报信息的发送等待时间，从而减小上报信息的时延。

Description

一种信息的传输方法、终端和网络设备

技术领域

本发明涉及通信领域,更具体的涉及一种信息的传输方法、终端和网络设备。

背景技术

近几年来，网络时延(Delay/Latency)性能越来越得到人们的重视，逐渐成为通信业界的新热点。低时延网络也成为运营商所关注的发展方向。随着“互联网+”的深入发展，电信网络开始与各行各业深度融合，某些新兴行业和新兴业务对网络时延提出了近乎苛刻的需求。比如电子交易、高清视频、云计算和未来5G等业务的发展，使得时延成为通信网络的重要性能指标，低时延也将成为未来运营商网络能力竞争的重要手段。

一般来说，现有的控制时延的方法往往从无线接入网、核心网或者互联网PDN(公共数据网，Public Data Network)网络的角度进行突破。TDD(Time Vivison Duplexing,时分双工)通信系统，就是使用TDD通信技术的系统。目前，TDD(Time Vivison Duplexing,时分双工)通信系统中的信息传输方式，使用的帧结构使得时延较大，无法满足网络中业务的需求。

发明内容

有鉴于此，本发明实施例提供了一种信息传输的方法、终端和网络设备，能够一定程度上减小一部分信息的发送等待时间，从而减小这部分信息的时延。

第一方面，本发明实施例提供了一种信息传输方法，该传输方法用于在时分双工TDD通信系统中通过多个子帧传输信息,所述时分双工TDD通信系统包括网络设备与终端，所述多个子帧包括第一子帧，所述第一子帧包括第一业务信道和第一上行请求信道，，所述传输方法包括：所述网络设备通过所述第一业务信道与所述终端传输数据。S503：所述网络设备通过所述第一上行请求信道，接收所述终端的上报信息，所述上报信息为第二业务的数据传输请求、第三业务的数据和预设的紧急指令的反馈消息中的至少一种，所述第二业务和所述第三业务为预设的紧急业务。

这样，可以通过该第一上行请求信道，将紧急业务的请求、数据和预设的紧急指令的反馈消息上报给网络设备，在一个子帧中有业务信道和上行请求信道，给紧急业务和紧急指令的反馈消息预留了资源，使得这些上报信息可以及时而灵活地上报，而不需要等待到正在传输的数据发完，在传输方向合适的子帧进行传输，从而减小了这部分对时延要求的较高的上报信息发送等待时间，从而减小这部分信息的时延。

应理解，网络设备可以采用广播或者定向传输的方式，与一组终端使用第一子帧的帧结构进行通信，该一组终端可以包括一个或多个终端，例如该一组终端为该网络设备的所服务的某一个广播组中的终端或者与某一个业务相关的列表中的终端，或者该网络设备所服务的小区中的一个或者多个终端等。

应理解，普通数据为可容忍现有技术的TDD协议中帧格式所产生的时延的数据。具体的，普通数据对实时性要求不高，并且也对数据传输过程中的干扰和错误的容忍度也较高。紧急数据为不可容忍现有技术的TDD协议中帧格式所产生的时延的数据。具体的，紧急数据但由于对实时性要求较高，需要终端或者网络侧迅速做出反应，故要求更准确快速的传输，对数据传输过程中的干扰和错误的容忍度较低，用传统LTE协议传输不能满足这些要求，会影响紧急数据所对应的业务的执行，这种影响在上述的广覆盖或者深覆盖场景中影响更大，往往时延长达几十秒，这可能导致网络侧无法及时控制终端，如指令不能及时下达等，因此，紧急数据更适合使用本发明实施例中的方法进行处理。

故，本发明实施例提出一种信息传输方法，用于在时分双工TDD通信系统中通过多个子帧传输信息。其中，使用一种新的子帧，不再用帧为单位来考虑数据的传输，不再有明确的帧的概念，也不再有明确的子帧比例，而是以能够更加灵活地传输数据，减少数据传输的等待时间，也就是减少了时延。该子帧在时分双工TDD通信系统的网络侧设备(如基站、网关)和终端(如平板电脑、手机、电表等)之间进行传输。例如，这种子帧可以通过广播的形式在一个网络侧设备与该网络侧设备覆盖的广播区域(如小区)中的多个终端之间传输。

结合第一方面，在第一方面的第一种可能的实现方式中，所述第一子帧为下行子帧，所述第一间隔与所述第一上行请求信道相邻所述第一子帧还包括第一间隔，并且所述第一间隔与所述第一上行请求信道相邻，在所述第一间隔内，所述网络设备与所述终端停止通信，所述网络设备通过所述第一业务信道与所述终端传输第一业务的数据，包括：所述网络设备通过所述第一业务信道向所述终端发送第一业务的数据。这样，该第一间隔可以避免该网络设备与该终端在第一子帧传输的数据不被该网络设备所在小区内的其他终端干扰。

结合第一方面或第一方面的第一种可能的实现方式，在第一方面的第二种可能的实现方式中，所述第一上行请求信道为所述第一子帧的倒数第二个正交分频复用OFDM符号(symbol)。

这样，如果终端在该第一上行请求信道中要求向网络设备上报紧急数据，在第一子帧的下一个子帧，网络设备就可以告诉终端，该下一个子帧可以上报数据，从而减少终端上报数据的等待时间。即第一子帧和第二子帧是相邻的子帧。

另一方面，该第二种可能的实现方式还可以包括，所述下行紧急控制信道为所述第二子帧的第一个OFDM符号。这，终端就可以跟进该第二子帧的中的控制信息上报该第二业务的数据，减小第二业务的数据的传输时延。结合第一方面到第一方面的第二种可能的实现方式中的任一种，在第一方面的第三种可能的实现方式中，所述第一上行请求信道仅用于传输所述上报信息。这样，可以保证这些与紧急业务或者紧急指令相关的上报信息能独占第一上行请求信道，而不被普通数据占用，从而保证这些上报信息的及时上报，减小其时延。

结合第一方面到第一方面的第三种可能的实现方式中的任一种，在第一方面的第四种可能的实现方式中，所述多个子帧还包括第二子帧，所述第二子帧在所述第一子帧之后，所述上报信息包括所述第二业务的数据传输请求，所述第二子帧包括第二下行紧急控制信道和第二业务信道，所述方法还包括：所述网络设备根据所述第二业务的数据传输请求，通过所述第二下行紧急控制信道向所述终端发送第二控制信息，所述第二控制信息用于指示在所述第二业务信道内，所述网络设备与所述终端之间的信息传输方式为上行传输；所述网络设备通过所述第二业务信道，接收所述终端发送的所述第二业务的数据。

结合第一方面的第四种可能的实现方式，在第一方面的第五种可能的实现方式中，第二子帧还包括第二间隔，所述第二间隔位于所述第二业务信道与所述第二下行紧急控制信道之间，在所述第二间隔内，所述网络设备与所述终端停止通信。该第二间隔可以避免该网络设备与该终端在第二子帧传输的数据不被该网络设备所在小区内的其他终端干扰。

结合第一方面第四种或者第五种可能的实现方式中的任一种，在第一方面的第六种可能的实现方式中，所述方法还包括：所述网络设备通过所述第二下行紧急控制信道向所述终端发送数据。

这样，下行紧急控制信道也可以用于传递数据，充分利用了子帧的信道资源，使一个子帧中用于传输数据时间尽可能长，提高了子帧的利用率。例如，在控制信息较少或者在某些与现有的帧结构混用的情况下，第一子帧按照原本的配置为上行或者下行子帧，而刚好第一子帧又无需改变原本的配置，该下行紧急控制信道就不会因空置而浪费，可以用于传输数据，相当于最大限度地使用了子帧能够传输数据的资源，提高了子帧的利用率。在一种实现方式下，该多个子帧中的每个子帧都包括下行紧急控制信道和业务信道。另一方面，一个子帧中可以有多个下行紧急控制信道和多个业务信道，对每个下行紧急控制信道，该下行紧急控制信道在该下行紧急控制信道对应的业务信道(即该下行紧急控制信道可用于指示其对应的业务信道的传输方式)之前。

结合第一方面第一到第六种可能的实现方式中的任一种，在第一方面的第七种可能的实现方式中，所述多个子帧还包括第三子帧，所述第三子帧包括第三下行紧急信道、第三业务信道以及第三上行请求信道，所述第三下行紧急信道在所述第三业务信道以及所述第三上行请求信道之前，所述方法包括：所述网络设备通过所述第三下行紧急控制信道向所述终端发送第三控制信息，所述第三控制信息用于指示在所述第三子业务信道内，所述网络设备与所述终端间的信息传输方式，所述信息传输方式为上行传输或者下行传输；所述网络设备通过所述第三业务信道，使用所述信息传输方式与所述终端进行通信；所述网络设备通过所述第三上行请求信道，接收所述终端的上报信息，所述上报信息为第四业务的数据传输请求、第五业务的数据和预设的紧急指令的反馈消息中的至少一种，所述第四业务和所述第五业务为预设的紧急业务,所述第三上行请求信道仅用于传输所述上报信息。

这样，该多个子帧的子帧结构更加多样，一个子帧中有上行请求信道和下行紧急控制信道，使得对子帧的控制更加有效，数据上报的更加灵活，减少了数据上报的等待时间。

需要说明的是，该第三子帧中信息传输方式也可以是上行传输与下行传输，则该第三子帧包括多个业务信道，其中至少一个业务信道为上行传输，至少一个业务信道为下行传输，该第三子帧中的多个业务信道的配置信息(例如各个业务信道的长度、位置、频率等)都可以通过下行紧急控制信道，向终端传达。应理解，为了保证数据传输不受其他终端的干扰，数据传输方式不同的业务信道之间可以有保护间隔。

需要说明的是，网络设备可以通过广播信道发送切换指令，该切换指令用于在该网络设备所在的网络中开启或者关闭本发明实施例所描述的子帧的传输。或者通过广播信道中的系统信息块(SIB,System Information Block)中的一个1bit来实现该指示指令的作用，该SIB可以是广播信道发送的小区信息的一部分。

第二方面，本发明实施例提供一种信息传输方法，所述传输方法用于在时分双工TDD通信系统中通过多个子帧传输信息,所述时分双工TDD通信系统包括网络设备与终端，所述多个子帧包括第一子帧，所述时分双工TDD通信系统包括网络设备和终端，所述多个子帧包括第一子帧，所述第一子帧包括第一业务信道和第一上行请求信道，所述传输方法包括：所述终端通过所述第一业务信道与所述网络设备传输第一业务的数据；所述终端通过所述第一上行请求信道，向所述网络设备发送上报信息，所述上报信息为第二业务的数据传输请求、第三业务的数据和预设的紧急指令的反馈消息中的至少一种，所述第二业务和所述第三业务为预设的紧急业务。

由于第二方面提供的是终端侧执行第一方面所述的内容的方法，内容与第一方面相应，故有关第二方面的各种可能的实现方式、说明以及技术效果，请参见第一方面的描述，此处不再赘述。

第三方面，本发明实施例提供一种网络设备，所述网络设备用于在时分双工TDD通信系统中通过多个子帧传输信息,所述时分双工TDD通信系统包括网络设备与所述终端，所述多个子帧包括第一子帧，所述第一子帧包括第一业务信道和第一上行请求信道，所述网络设备包括：数据传输模块，用于通过所述第一业务信道与所述终端传输数据；请求接收模块，用于通过所述第一上行请求信道，接收所述终端的上报信息，所述上报信息为第二业务的数据传输请求、第三业务的数据和预设的紧急指令的反馈消息中的至少一种，所述第二业务和所述第三业务为预设的紧急业务。

第四方面，本发明实施例提供一种网络设备，所述网络设备用于在时分双工TDD通信系统中通过多个子帧传输信息,所述时分双工TDD通信系统包括所述网络设备与终端，所述多个子帧包括第一子帧，所述多个子帧包括第一子帧，所述第一子帧包括第一业务信道和第一上行请求信道，所述网络设备包括处理器和收发器，所述处理器用于通过所述收发器，执行第一方面或者第一方面任一种实现方式的方法。

由于第三方面和第四方面提供的网络设备是第一方面提供的方法所对应的装置，故有关第三方面和第四方面各种可能的实现方式、说明以及技术效果，请参见第一方面的描述，此处不再赘述。

第五方面，本发明实施例提供一种终端，所述终端用于在时分双工TDD通信系统中通过多个子帧传输信息,所述时分双工TDD通信系统包括网络设备与所述终端，所述时分双工TDD通信系统包括网络设备和终端，所述多个子帧包括第一子帧，所述第一子帧包括第一业务信道和第一上行请求信道，所述终端包括：数据传输模块，用于通过所述第一业务信道与所述网络设备传输第一业务的数据；请求上报模块，用于通过所述第一上行请求信道，向所述网络设备发送上报信息，所述上报信息为第二业务的数据传输请求、第三业务的数据和预设的紧急指令的反馈消息中的至少一种，所述第二业务和所述第三业务为预设的紧急业务。

第六方面，本发明实施例提供一种终端，所述终端用于在时分双工TDD通信系统中通过多个子帧传输信息,所述时分双工TDD通信系统包括网络设备与所述终端，所述多个子帧包括第一子帧，所述第一子帧包括第一业务信道和第一上行请求信道，所述终端包括处理器和收发器，执行第二方面或者第二方面任一种实现方式。

由于第五方面和第六方面提供的网络设备是第二方面提供的方法所对应的装置，故有关第五方面和第六方面各种可能的实现方式、说明以及技术效果，请参见第二方面的描述，此处不再赘述。

第七方面，本发明提供一种存储介质，该介质用于存储用于执行第一方面或者第一方面的任意一种实现方式的方法的程序。或者，该介质用于存储用于用于执行第二方面或者第二方面的任意一种实现方式的方法的程序。

附图说明

为了更清楚地说明本发明实施例中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例记载的方法适用的一种TDD通信系统组网示意图；

图2为本发明实施例提供的云通信场景示意图；

图3为本发明实施例提供的多种用于TD-LTE系统的帧结构的示意图；

图4为本发明实施例提供的IoT 230系统的无线帧的结构的示意图；

图5为本发明实施例提供的一种信息传输方法的流程示意图；

图6为本发明实施例提供的传输信息涉及的信息干扰的示意图；

图7为本发明实施例提供的一种在宽带系统和窄带系统中可采用的控制信息分布的示意图；

图8为本发明实施例提供的一种上行紧急数据传输的子帧结构中的交互流程图；

图9为本发明实施例提供的一种下行紧急数据传输的子帧结构中的交互流程图

图10为本发明实施例提供的一种在IoT230系统中的帧的改进结构的示意图；

图11为本发明实施例提供的另一种在IoT230系统中的帧的改进结构的示意图；

图12为本发明实施例提供的一种在IoT230系统中传输下行的紧急数据的示意图；

图13为本发明实施例提供的一种在IoT230系统中传输上行的紧急数据的示意图；

图14为本发明实施例提供的使用一种改良帧结构进行数据传输的示意图；

图15为本发明实施例提供的一种网络设备的示意图；

图16为本发明实施例提供的一种终端的示意图；

图17为本发明实施例提供的一种用于执行本发明实施例所述方法的装置的示意图。

具体实施方式

本发明实施例提供了一种信息传输的方法、装置和系统，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

首先，对本发明实施例中出现的若干名词进行解释。

应理解，本申请实施中涉及到的第一、第二、第三这一类词，并不表示任何顺序，而是在描述相同类型的事物时为了描述方便而使用，例如，第一子帧、第二子帧、第三子帧，都是子帧。再例如，第一业务信道、第二业务信道、第三业务信道都是业务信道，若理解为第一业务的信道、第二业务的信道、第三业务的信道则是不恰当的。在某些情况下，这些词可以指代相同类型的同一事物，例如，第二业务、第三业务、第四业务和第五业务中的任意一个业务可以是相同的业务。

本申请文件中所述的TDD通信系统，指的是支持使用TDD通信技术的进行通信的系统。本申请文件中所述的TDD系统包括网络设备和终端，是指该网络设备与终端之间能够使用本申请文件描述的信息传输方法进行通信。也就是说，这种包括不是从组网形式或者组网结构上来描述，而是从该网络设备与终端支持的相同的通信技术，即TDD通信技术的角度来描述。因为终端是可以移动的，一般现有的描述方式，从组网形式的角度，不将终端明确划归在某个通信系统中。也就是说，网络设备为支持使用TDD通信技术的网络设备，终端为为支持使用TDD通信技术的终端。换言之，本申请文件中所述的TDD系统包括的网络设备和终端，并不要求在具体的组网形式或者组网结构中，该网络设备和终端必须处在一个组网架构下，只要都支持使用TDD通信技术即可。

本发明实施例中的终端，可以是移动终端(Mobile Terminal)，例如手机、平板电脑、运动相机、笔记本电脑等便携式、穿戴式、或者车载的移动设备，也可以是一些能够接入通信网络的计算机、服务器等设备，甚至是能够接入使用TDD技术进行通信的电表、水表、煤气表等，以及其他可以使用TDD技术进行通信的终端设备。本发明实施例所述的网络设备，可以是基站、服务器代理服务器等设备，也可以是能够使用TDD技术的路由器、网关等设备等，以及其他可以使用TDD技术进行通信的网络设备。本发明实施例对终端和网络设备的具体种类不做限制。

本发明实施例所述的方法可用于使用TDD技术的多种通信系统。当然，FDD(频分复用，Frequency Division Duplexing)系统也可以使用。例如电力通信系统中(其网络架构可以参考示意图图1)，有一套基于TDD的通信控制系统，用于对电表数据进行监控和采集，该系统中包括多个终端，这些终端可以用于采集电表数据，接收和转发控制指令等，这些终端通过基站与该通信控制系统的核心控制设备进行通信，该系统中的基站等网络设备和终端之间的通信即可使用该方法，以支撑电力系统的用电采集，应急抢修，配电自动化，以及故障检测传感设备的信息上报等业务。例如在这些业务中，许多关键控制信息如紧急业务的控制信号的传输，需要在最快的时间内可靠传达，再比如电网中引入的新能源因为输出功率的不稳定性特性，需要实时的检测和控制，都对信息传输的实时性有较高要求。

再比如，云计算、大数据、物联网等发展趋势使得越来越多的业务运行在云(cloud)上，云已经成为通信网络无法回避的趋势，而作为云的物理载体——数据中心逐渐成为网络流量的核心，数据中心要为网络中许多的终端提供服务，数据在数据中心内部、数据中心之间以及数据中心与终端之间的迁移越来越频繁，这种迁移可称为云通信业务,云通信业务中，有一部分对实时性要求较高，如虚拟机热迁移通、云数据热备份、云灾备、高通量协同计算等，又比如随着市场发展，而逐渐迁移到云上的一些应用层业务，如云支付业务，云桌面业务等，图2包括了一些典型的云通信场景，其中的即时消息，音频和电话、视频、应急消息等，这些业务直接面向用户，对实时性要求也较高。

在使用TTD技术的系统中，物理层使用TTD的帧进行通信，TTD技术的帧表示一个固定的时长，该帧所包括的时长称为帧的长度。通常，每个帧包括一定数量的子帧，每个子帧时长固定，每个子帧又由若干个OFDM(Orthogonal Frequencey-division Multiplexing，正交分频复用)符号(symbol)组成，帧的长度也可以用帧中包括的子帧个数来标识。每个子帧是一个数据传输单元，用于上行传输(数据流向为终端到数据中心)数据、下行传输(数据流向为数据中心到终端)数据或者控制。通常，一个帧的长度，中包括的子帧数目，以及这些子帧中分别负责上下行数据传输的子帧数目都是预先配置好的，也就是遵照某种协议或者版本而固定下来的，例如，图3展示了7种TD-LTE帧结构，每种帧结构中上行子帧和下行子帧的数目都是固定的，切换周期有5ms和10ms两种配置，对应的特殊子帧(用于上下行切换)个数为1和2。图3所示的下行子帧为主的有4种配置(configuration 2/3/4/5)，上行子帧为主的有2种配置(configuration 0/6)，上下行均衡的配置有1种(configuration 1)。其中，D代表下行传输单元(下行子帧)，S代表特殊子帧，U代表上行传输单元(上行子帧)。因此，数据必须要等到相应的子帧状态到来时才能传输，时延问题比较严重。以图4所示的IoT 230系统的无线帧的结构为例，该帧结构中一个无线帧包括15个子帧,长度为120ms(毫秒)，其中上下行分别有7个子帧,每个子帧的长度为8ms，每个子帧里面有10个OFDM symbols。中间一个为特殊子帧,这一特殊子帧就是用作上行传输单元，作为上行随机接入过程的PRACH(Physical Random Access Channel,物理随机接入信道)，前面7个子帧为下行传输单元(Down Link,DL)，后面7个子帧为上行传输单元(Up Link,UL)。无线通信系统的传输时间间隔(transmission time interval，TTI)是基于子帧的，在通常场景下，TTI为一个子帧，则如果在上行子帧过程中想要传输下行的紧急数据，需要等待上行子帧来临，那么下行传输的最大时延为8个子帧长，类似的，上行时延最大为24个子帧长，而在要求广覆盖深覆盖的场景下，时延会更长。应理解，在另一种系统或者协议下，帧的长度、上下行传输单元的配比等都有可能不同，例如中国普天LTE230，子帧长度为5ms,上行子帧和下行子帧的数量配比为3:1或者2:2。

可以理解的是，在现有技术中，上行子帧和下行子帧中只有业务信道，业务信道用于传输数据(信息、指令也是一种数据)，该业务信道的传输方向为上行传输，则该子帧为上行子帧，该业务信道的传输方向为下行传输，则该子帧为下行子帧。

可见，由于帧结构中上下行子帧的固定，在数据传输过程中，如果有不同于当前子帧的传递方向的数据需要传输，例如在下行子帧中，终端有紧急情况要上报，或者在上行子帧中，网络侧有紧急命令要下达，都只能等待到相应的子帧才能传输，故时延较长。另一方面，实际的组网要考虑该网络支持的业务的需求，例如，广覆盖和深覆盖都是非常常见的需求。广覆盖指的是要用有限的基站支持大量设备连接；深覆盖指的通信中信息的传输要覆盖系统内位于大型建筑内部的大量终端，例如在能源互联网应用市场，智能电网等。在这种广覆盖或者深覆盖的系统中要保证信号的正确传输，需要保证信号源的能量，能量等于功率乘以时间，然而信号源的功率是有明确的法规规定的上限的，因此这类系统只能增长发送数据的时间，也就是说，数据重复传输多次即TTI加长，且数据一旦传输就不能被打断，数据传输完还要等待到具有合适的信息传输方式的子帧才可以传输新的数据，时延非常大。并且，即使是相同的传输方向，由于一段时间内要传输的数据的包是一定的，在这段时间内产生的同传输方向的紧急数据也会由于子帧的资源被这一组数据的包占用而无法传输，导致需要在这组数据传输完成后，在合适的子帧中才能够传输。例如物联网应用市场中的属于massive IoT技术的NB-IoT系统，上行TTI达到40960ms。然而，这种广覆盖或者深覆盖的系统中，又经常需要传输一些小流量但突发性强的紧急数据，例如智能电网配电自动化场景中电力业务控制指令或者上报故障电机等，这类信息的传输又有低时延的要求，对通信的时延要求很高。因此，在广覆盖网络或深覆盖网络中，时延问题更加明显，显然，本发明实施例记载的方法对这类网络是适用的。

在本发明实施例中，普通业务的数据就是普通数据。本申请后文也使用普通数据来表示普通业务的数据。也就是说，普通数据为可容忍现有技术的TDD协议中帧格式所产生的时延的业务的数据。具体的，普通数据对实时性要求不高，并且也对数据传输过程中的干扰和错误的容忍度也较高。紧急业务的数据就是紧急数据。本申请后文也使用紧急数据来表示紧急业务的数据。也就是说，紧急数据为不可容忍现有技术的TDD协议中帧格式所产生的时延的业务的数据。具体的，紧急数据但由于对实时性要求较高，需要终端或者网络侧迅速做出反应，故要求更准确快速的传输，对数据传输过程中的干扰和错误的容忍度较低，用传统LTE协议传输不能满足这些要求，会影响紧急数据所对应的业务的执行，这种影响在上述的广覆盖或者深覆盖场景中影响更大，往往时延长达几十秒，这可能导致网络侧无法及时控制终端，如指令不能及时下达等，因此，紧急数据更适合使用本发明实施例中的方法进行处理。

从上文可看出，普通数据和紧急数据可以通过数据对应的业务的类型来区分。例如，电网中，紧急故障(如电表烧毁、电路短路等)的通知信息、应急抢修业务的控制信息或者配电自动化业务的控制信息等是紧急数据，抄表业务涉及的信息是普通数据。另一方面，普通业务的数据和紧急业务的数据还可以通过数据结构来进行标识。例如，可以将数据的头部加上扰码序列以表示该数据为紧急业务的数据，或者给数据头部留一个标志位，以不同的赋值来区分普通业务的数据和紧急业务的数据，或者通过不同的封装格式来区分普通业务的数据和紧急数据等。本发明实施例普通数据与紧急数据的区分方式不做限定。

应当理解，在一种实现方式下，紧急业务是预设的。例如用于表示紧急业务的信息(如标识)维护在网络设备和终端，或者在网络设备和终端中，通过某种标记指示某些业务为紧急业务。例如这些紧急业务是由管理员或者系统根据该系统的使用场景和功能确定出比较紧急的业务。也就是说，在本申请实施例中，网络设备和终端都知道哪些业务是紧急业务。

需要理解的是，在TDD通信中，一般采用协议规定数据传输的时序和通信交流方式(如帧结构)，在传输过程中，网络设备占据控制地位，例如当终端需要上报信息时，首先要向基站请求上报，基站收到上报请求才会分配资源(如物理信道、发送数据的子帧等)给终端，这个分配资源过程也就是调度。也就是说即使是上行传输，终端使用的资源仍然由基站来调度。终端根据基站分配的资源上传数据，而由于资源是基站分配给终端的，故基站很明确在什么时间从哪个物理信道接收终端发送的数据来进行解调。

再例如，基站在传输普通下行数据的时候，基站会通过PDSCH(Physical DownlinkShared Channel，物理下行共享信道)承载要传输的下行数据，并且通过PDCCH(PhysicalDownlink Control Channel，物理下行控制信道)告诉终端传输该普通数据的PDSCH在哪个频段，这样终端就先根据PDCCH找到PDSCH，以接收和解析出下行数据。同理，终端要发上行数据但是没有上行资源(例如网络侧未分配上行的信道)的情况下，终端向基站发完调度请求(Scheduling Request，调度请求)之后，基站会通过PDCCH告诉终端PUSCH(PhysicalUplink Shared Channel，物理上行共享信道)在哪里，终端根据PDCCH找到PUSCH，以使用PUSCH发送上行数据。具体的，上述过程中的SR可以通过PRACH(Physical Random AccessChannel，物理随机接入信道)传输。需要说明的是，普通数据的传输过程中，上行或者下行传输的子帧并不是只能传数据，相同数据流向的控制信息、调度信息等都可以在数据部分的资源单元(Resource Element，RE)RE承载。

本领域技术人员应理解，RE就是RB(resource block资源块)中的单位资源，RB是承载数据的单位，1个RB代表一个子帧的资源，从时域和频域进行定义，1个RE表示时域的一个OFDM符号的时间长度以及频域的1个子载波。例如，在一种帧结构下，1个RE表示时域的10个OFDM符号的时间长度，频域上带宽为25KHz，包括16个带宽为1.5625KHz的子载波。

一般来说，TDD通信系统中，子帧的传输依赖上行和下行的物理信道，具体可参见上述描述普通数据传输的相关段落，对于一对通信设备，例如一终端和一基站，二者间进行通信的物理信道对应于一个RB所包括的一组资源单元(resource element,RE)，这些RE承载有来自物理层的信息。上下行均有多种物理信道，比如本专利涉及到的控制信道，数据信道等。每个RE在时域上的长度为一个OFDM symbol的长度，一组RE组成资源块(时域上包括一组连续的OFDM符号，频域上包括一组连续的子载波)，一般来说，一个资源块和一个终端的物理信道之间具有映射关系，如果一个资源块要供多个终端使用，则需要借助其他技术，例如码分多址技术CDMA。

故，本发明实施例提出一种信息传输方法，用于在时分双工TDD通信系统中通过多个子帧传输信息。其中，使用一类新的子帧，不再用帧为单位来考虑数据的传输，不再有明确的帧的概念，也不再有明确的子帧比例，在这类新的子帧的结构中，引入了上行请求信道和下行紧急控制信道中的至少一种，从而能够更加灵活地传输信息，减小一部分信息的发送等待时间，从而减小这部分信息的时延。尤其是对紧急业务的信息。本申请实施例中的子帧在时分双工TDD通信系统的网络侧设备(如基站、网关)和终端(如平板电脑、手机、电表等)之间进行传输，当然，也可以在TDD通信系统的网络设备之间传输。例如，这类子帧可以通过广播的形式在一个网络侧设备与该网络侧设备覆盖的广播区域(如小区)中的多个终端之间传输。

网络设备可以采用广播或者定向传输的方式，与一组终端使用下述的第一子帧、第二子帧以及第三子帧中的至少一个的子帧结构进行通信，该一组终端可以包括一个或多个终端，例如该一组终端为该网络设备的所服务的某一个广播组中的终端或者与某一个业务相关的列表中的终端，或者该网络设备所服务的小区中的一个或者多个终端等。

应理解，下文中提及的各种子帧结构，可以是预先系统中设定好的子帧结构，终端与网络设备使用这类子帧结构进行通信，也就是说，下文中提及的上行请求信道和下行紧急控制信道使用无需网络设备通知终端。例如，规定一个帧中的子帧1,3,5中包括上行请求信道，且该上行请求信道在倒数第二个符号，则一旦确定使用这种子帧结构，终端和网络设备会在传输数据之前就通过广播的设置信息知道使用这种子帧结构，从而在相应的时间使用相应的信道。

在本发明实施例提出的子帧中的上行请求信道内，例如第一子帧的第一上行请求信道以及下文提及的第二子帧的第二上行请求信道等，终端通过上行请求信道向网络侧设备发送上报信息。

对该多个子帧中的第一子帧，包括第一业务信道和第一上行请求信道。其中，在一种实现方式下，该多个子帧中的至少一个子帧包括上行请求信道和业务信道。在另一种实现方式下，该多个子帧中的每个子帧包括上行请求信道和业务信道。另一方面，一个子帧中可以有多个上行请求信道和多个业务信道。

在一种实现方式下，该子帧中的基本时间单位仍然是OFDM symbols，也就是说一个子帧中包括多个OFDM symbols，上文中提及的下行紧急控制信道，业务信道和上行请求信道的时长也都是整数个OFDM symbols。为了说明方便，以该多个子帧中的第一子帧在一个网络设备和一个终端之间的传输过程，结合图5对该传输过程中包括的步骤进行说明。应当理解，由于一个网络设备可以服务多个终端，故具有该第一子帧结构的子帧可以同时在一个网络设备和多个终端之间传输，也可以在TDD通信系统中的多组网络设备和终端之间传输，本发明实施例不做限制。例如一个小区内基站和终端，或者多个小区内的基站和终端等等。

另一方面，一个子帧中可以有多个下行紧急控制信道和多个业务信道，对每个下行紧急控制信道，该下行紧急控制信道在该下行紧急控制信道对应的业务信道(即该下行紧急控制信道可用于指示其对应的业务信道的传输方式)之前。在一种实现方式下，该多个子帧的至少一个子帧，例如第三子帧，还包括下行请求信道。该传输方法包括：

S501：所述网络设备通过所述第一业务信道与所述终端传输数据。

S503：所述网络设备通过所述第一上行请求信道，接收所述终端的上报信息，所述上报信息为第二业务的数据传输请求、第三业务的数据和预设的紧急指令的反馈消息中的至少一种，所述第二业务和所述第三业务为预设的紧急业务。

应理解，事实上，该S501和S503仅仅是为了标识不同的步骤，并不限定步骤的先后顺序。也就是说从子帧结构看，第一上行请信道可以在第一业务信道之前或者在将第一业务信道分为两个部分。本发明实施例不做限定。

应理解，第二业务和第三业务，可以是相同的业务，也可以是不同的业务。数据传输请求，用于终端向网络设备请求上传一紧急业务的数据。下文中提及的第一业务，可以是紧急业务也可以是普通业务。在第一业务为紧急业务的情况下，可以与第二业务到第五业务(第四业务第五业务下文有提及)中的至少一个为相同的业务。

类似于上文中对紧急业务的描述，可以预设一些指令为紧急指令，紧急指令需要终端尽快地上报反馈消息，反馈消息例如可以是ACK或者NACK。应理解，这些紧急指令，可以是系统中某设备或者具有权限的用户设置的，使用本方法的网络设备和终端是经过协商确定的。例如可以在传输数据之前，网络设备可以通过广播的方式通知该小区内的终端哪些业务是紧急业务，哪些指令是紧急指令。

这样，可以通过该第一上行请求信道，将紧急业务的请求、数据和预设的紧急指令的反馈消息上报给网络设备，在一个子帧中有业务信道和上行请求信道，给紧急业务和紧急指令的反馈消息预留了资源，使得这些上报信息可以及时而灵活地上报，而不需要等待到正在传输的数据发完，在传输方向合适的子帧进行传输，减小了这部分信息的发送等待时间，从而减小了这部分对时延要求的较高的上报信息的时延。一种情况下，这种第一子帧的结构，可以在现有的帧结构架构下使用，在现有的帧结构中，每个子帧都默认为上行子帧或者下行子帧，在下行子帧显然是不能传输上行的数据的，必须要等到对应的上行子帧才行，而使用上述第一子帧的结构，则可以使用该第一上行请求信道及时地上报，保证了上报信息的时延能够满足紧急业务或者紧急指令的需要。

在一种情况下，该上行请求信道仅用于传输所述上报信息。这样，可以保证这些上报信息能够独占上行请求信道，从而保证这些上报信息能够尽快地上传，减小这些上报信息的时延。例如，该上报信息可以是SR(Schedul ing Request)。例如终端要上报紧急业务的数据时，需要向基站发出SR告知基站有上行紧急数据要传输，收到终端的SR之后，基站才会在下个子帧的下行紧急控制信道内通知终端在该子帧中做好准备，以在该子帧中上报数据配置需要变为适合上行紧急数据传输的结构。又例如，上行请求信道还可以传递一些数据量较小的紧急数据。再例如，该网络设备也可以通过该上行请求信道接收终端发送的紧急数据。也就是说，在终端有紧急的数据的情况下，该终端也可以不请求后面子帧的资源，直接向网络设备上报该紧急数据。这类直接上报的紧急数据往往数据量比较小。在特别紧急的情况下，终端直接上传紧急业务(上文中的第三业务)的数据，而不通过发送请求信息请求使用后面的子帧(例如下文中描述的第二子帧)的业务信道传输紧急数据(要使用业务信道传输的紧急数据一般数据量比较大，上行请求信道的长度不足以完成这些紧急数据的传输)。该特别紧急的情况可以对应前文的第三业务，例如具体可以是电表故障，电路烧毁等。

在一种实现方式下，所述第一上行请求信道为所述第一子帧的倒数第二个正交分频复用OFDM符号(symbol)。在一种实现方式下，该第一上行请求信道为所述第一子帧的倒数第二个正交分频复用OFDM符号(symbol)。这样，如果终端在该第一上行请求信道中要求向网络设备上报紧急数据(例如第二业务的数据传输请求)，在第一子帧的下一个子帧，网络设备就可以告诉终端，该下一个子帧可以上报数据，从而减少终端上报数据的时延。

而在一种实现方式下，该第一上行请求信道也可以是所述第一子帧的倒数第一个正交分频复用OFDM符号(symbol)。这样，需等到第一帧的下一个子帧的下一子帧，网络设备才可以告知终端在该下下个子帧上报数据，可见，时延比放在倒数第二个OFDM符号多一个子帧的长度。另一方面。在另一种实现方式下，该下行紧急控制信道为所述第一子帧的第一个OFDM符号。由于该下行紧急控制信道是用来指示该子帧内业务信道数据的传输方向的，这样放置，就可以及时地控制该第一子帧的业务信道，也可以使该第一子帧的业务信道尽量长，减少子帧中符号的浪费。

应理解，网络设备处于控制地位，可以根据网络设备与终端间业务的交互需要，或者对终端的控制需要决定在哪个子帧下发数据(例如电网中网络中的中央控制设备确定在某个时刻对该网络中的终端，如电表更新软件版本)，从而在该子帧的下行紧急传输信道发送控制信息，以告知终端该子帧要发送下行的数据(紧急数据和普通数据中至少一种)，以便终端在业务信道中接收发送的数据。

在一种实现方式下，所述第一子帧为下行子帧，所述第一子帧还包括第一间隔，并且所述第一间隔与所述第一上行请求信道相邻，在所述第一间隔内，所述网络设备与所述终端停止通信，所述网络设备通过所述第一业务信道与所述终端传输第一业务的数据，包括：所述网络设备通过所述第一业务信道向所述终端发送第一业务的数据。

应理解，对于第一间隔，该第一间隔的前后相邻的信道的传输方式不同。例如该第一间隔前紧邻下行传输的业务信道，该第一间隔后紧邻上行传输的第一请求请求信道；或者在第一请求请求信道在第一业务信道前的情况下，该第一间隔后紧邻下行传输的业务信道，该第一间隔前紧邻上行传输的第一请求请求信道。

在一种实现方式下，所述多个子帧还包括第二子帧，所述第二子帧在所述第一子帧之后，所述上报信息包括所述第二业务的数据传输请求，所述第二子帧包括第二下行紧急控制信道和第二业务信道，所述方法还包括：所述网络设备根据所述第二业务的数据传输请求，通过所述第二下行紧急控制信道向所述终端发送第二控制信息，所述第二控制信息用于指示在所述第二业务信道内，所述网络设备与所述终端之间的信息传输方式为上行传输；所述网络设备通过所述第二业务信道，接收所述终端发送的所述第二业务的数据。

该第二子帧可以是紧邻该第一子帧的下一个子帧，例如在第一子帧的第一上行请求信道在倒数第二个OFDM符号的情况下，也可以在第一子帧后而不与第二子帧相邻。

在一种实现方式下，下行紧急控制信道中下发的控制信息可以使用扰码序列来通知终端接下来的数据是紧急数据还是普通数据，即终端成功解扰码则表示紧急数据，接收该下行紧急数据，没有成功解扰码则默认接收普通数据。另一种实现方式下，下行紧急控制信道的控制信息可以是带有循环冗余校验码(Cryclical Redundancy Check,CRC)的信息比特，终端通过解码信息比特来获得该控制信息。在一种实现方式下，所述第二子帧还包括第二间隔，所述第二间隔位于所述第二业务信道与所述第二下行紧急控制信道之间，在所述第二间隔内，所述网络设备与所述终端停止通信。

在一种实现方式下，所述网络设备通过所述第二下行紧急控制信道向所述终端发送数据。实际上，网络设备也可以通过下文描述的第三下行紧急控制信道向所述终端发送数据，可以是紧急数据也可以是普通数据。这样，下行紧急控制信道不仅可以用于下发控制信息，也可以用于传递数据，充分利用了子帧的信道资源，使一个子帧中用于传输数据时间尽可能长，提高了子帧的利用率。例如，在控制信息较少或者在某些与现有的帧结构混用的情况下，第三子帧按照原本的配置为上行或者下行子帧，而刚好第三子帧又无需改变原本的配置，该下行紧急控制信道就不会因空置而浪费，可以用于传输数据，相当于最大限度地使用了子帧能够传输数据的资源，提高了子帧的利用率。在一种实现方式下，该多个子帧中的每个子帧都包括下行紧急控制信道和业务信道。另一方面，一个子帧中可以有多个下行紧急控制信道和多个业务信道，对每个下行紧急控制信道，该下行紧急控制信道在该下行紧急控制信道对应的业务信道(即该下行紧急控制信道可用于指示其对应的业务信道的传输方式)之前。

在一种实现方式下，所述多个子帧还包括第三子帧，所述第三子帧包括第三下行紧急信道、第三业务信道以及第三上行请求信道，所述第三下行紧急信道在所述第三业务信道以及所述第三上行请求信道之前，所述方法包括：

所述网络设备通过所述第三下行紧急控制信道向所述终端发送第三控制信息，所述第三控制信息用于指示在所述第三子业务信道内，所述网络设备与所述终端间的信息传输方式，所述信息传输方式为上行传输或者下行传输；所述网络设备通过所述第三业务信道，使用所述信息传输方式与所述终端进行通信；

所述网络设备通过所述第三上行请求信道，接收所述终端的上报信息，所述上报信息为第四业务的数据传输请求、第五业务的数据和预设的紧急指令的反馈消息中的至少一种，所述第四业务和所述第五业务为预设的紧急业务,所述第三上行请求信道仅用于传输所述上报信息。

应理解，在一种情况下，该控制信息用于指示在所述第三子帧的业务信道以及所述第三子帧接下来的至少一个子帧的业务信道的信息传输方式。这种情况下，所述第三子帧后接下来的至少一个子帧为该子帧后的至少一个连续的子帧，且，该至少一个连续的子帧中有一个子帧与第三子帧相邻。这种情况下，该第三子帧接下来的至少一个子帧中无需下行紧急控制信道。从而使得控制更加灵活，且提高子帧传输数据的利用率，降低子帧的开销。

有了下行紧急控制信道，网络设备和终端传输数据就更加灵活，在有需要的场景下，子帧网络侧可以与终端协商数据传输的方式，从而更快地下发或者接受上传的数据，从而减少这些信息的发送等待时间，从而减小这部分信息的时延。。这种方法尤其适合有紧急数据的情况下。

也就是说，一个子帧中可以既包括上行请求信道，又包括下行紧急控制信道。这样就兼具了上行请求信道和下行紧急控制信道的优点，相关说明请参见上文，此处不再赘述。还需说明的是，上述文中提到的一些下行紧急控制信道，如第二下行紧急控制信道、第三下行紧急控制信道等，为所在子帧的第一个OFDM符号。这样，如果终端在该第二子帧或者第三子帧之前的一个子帧的第一上行请求信道中要求向网络设备上报紧急数据，在第一子帧的下一个子帧，网络设备就可以告诉终端，该下一个子帧可以上报数据，从而减少终端上报数据的时延。

当然，第三子帧也可以类似于第二子帧或者第一子帧那样，在其中包括第三间隔或者第四间隔。在第三业务信道的传输方式为上行传输的情况下，第三上行请求信道和第三业务信道之间包括第三间隔，在该第三间隔中，网络设备与终端停止通信。在第三业务信道的传输方式为下行传输的情况下，第三业务信道与第三下行紧急信道之间包括第四间隔，在该第四间隔中，网络设备与终端停止通信。

下行紧急控制信道中，网络设备可以使用该下行控制信道传递控制信息，以通知终端在该子帧接下来的时间段内将要进行的传输状态是单一的上行还是单一的下行或者既有上行传输又有下行传输，甚至还可以明确指示该子帧的结构，包括什么样的时间段，各时间段的时长等。终端就可以根据接收到控制信息，准备上传信息或者接收信息的资源，进而在该控制信息所在的子帧的业务信道中对应地进行传输。应理解，下行紧急控制信道可以通知终端该子帧的结构和配置，如该子帧中包括多少个业务信道，这些业务信道在子帧中的位置、长度以及信息传输方式等。例如终端可以通过下行紧急控制信道中下发的控制信息中，携带的某一个标志位的布尔值确定网络设备是否有紧急数据要下发。

有了下行紧急控制信道，网络设备和终端传输数据就更加灵活，在有需要的场景下，子帧子帧网络侧都可以与终端协商数据传输的方式。这一作用在紧急数据传输的时候尤其重要，因为普通数据会按照协议中规定的默认的数据传输状态传输，而如果在普通数据的传输过程中，突然有与普通数据流向不同的紧急数据需要传输，网络侧必须提前在下行紧急控制信道上通知终端当前传输单元的配置变化，才能协调紧急数据和普通数据传输。下行紧急控制信道还可以用于网络侧向终端发送对应上一个子帧的上行传输过程的ACK(Acknowledgement，确认字符)/NACK(Negative Acknowledgment,否定回答)。

对于上文中提及的第二上行请求信道和第三上行请求信道，请参照对前文第一上行请求信道的说明。

对于上文中提及的控制信息，例如第二控制信息和第三控制信息，用于指示在该控制信息对应的子帧的的业务信道内，所述网络设备与所述终端间的信息传输方式，所述信息传输方式为上行传输或者下行传输。

或者，在一种情况下，该控制信息用于指示在该控制信息所在的子帧的业务信道以及该控制信息所在的子帧接下来的至少一个子帧的业务信道的信息传输方式。这种情况下，该控制信息所在的子帧后接下来的至少一个子帧为该子帧后的至少一个连续的子帧，且，该至少一个连续的子帧中有一个子帧与该控制信息所在的子帧相邻。这种情况下，该该控制信息所在的子帧接下来的至少一个子帧中无需下行紧急控制信道。从而使得控制更加灵活，且提高子帧传输数据的利用率，降低子帧的开销。

在一种实现方式下，信息传输方式也可以是上行传输与下行传输，例如对上文中的第二子帧或者第三子帧，则该第二子帧或者第三子帧包括多个业务信道，至少一个业务信道为上行传输，至少一个业务信道为下行传输，该第二子帧或者第三子帧中的多个业务信道的配置信息(例如各个业务信道的长度、位置、频率等)都可以通过下行紧急控制信道，向终端传达。

应理解，本申请实施例中提及的这多种子帧，也可以根据一子帧中业务信道的传输方式，将该子帧描述为上行子帧或者下行子帧。而对于既包括上行传输的业务信道又包括下行传输的业务信道的子帧，可以根据上行传输和下行传输的业务信道所占符号的比例，以占比大的业务信道的传输方式描述该子帧。

应该理解，在一种实现方式下，业务信道也是可以传输该上报信息的。但是一般来说，在上行子帧中的业务信道传输的是上行的普通数据。

业务信道用于使用上行传输或者下行传输在网络设备与终端之间传输数据。例如上文中提及的第一、第二、第三业务信道，都是业务信道。需要说明的是，该业务信道中可以传输普通数据与紧急数据中的至少一种。由于一个网络设备往往能服务多个终端，故在一种实现方式下，在第一子帧的业务信道内，上报普通数据的终端可以根据在下行紧急控制信道中收到的信息，将用于上报数据的资源(如信道等)让出，以保障上报紧急数据的终端与网络设备间的通信。

应当理解，网络设备采用可以上述提及的第一子帧、第二子帧以及第三子帧中的至少一种与一组终端进行通信，例如该组终端包括在同一小区的多个终端。在一种实现方式下，对该同一小区内的这多个终端，在相同的业务信道中，使用相同的信息传输方式。需要解释的是，该网络设备与该一组终端的时间是同步的，相同的业务信道在时域上表示相同的时间段。换句话说，这表示网络设备要求同一小区的多个终端在同一传输业务数据的时间段(即相同的业务信道)内，都向网络设备上行传输数据或者都接收网络设备下行传输的数据。这样一来，同一小区的信息传输方式在业务信道就同步了，同一小区内的终端之间不会因信息传输方式不同而互相干扰。

以及，在某一终端需要发送上行的紧急数据的情况下，该小区网络设备指示某业务信道的信息传输方式为上行传输，相关小区(如相邻小区，或者能够接收到该小区内上报数据的终端的信号的小区)内的基站也可以下发指示在该相关小区内的终端，在相同时间段内的业务信道的信息传输方式也为上行传输。这样，该小区内的终端就不会对相关小区内在进行下行传输数据的终端产生干扰。甚至在一种实现方式下，可以使该相关小区的终端协助该终端发送上行的紧急数据到该相关小区对应的基站，然后基站之间再通过通信(如通过有线通信接口、光纤等)将收到的上行的紧急数据汇集到需要上报紧急数据的终端所在小区的基站，从而提高紧急数据上报的成功率和效率。另一方面，在某一终端需要接收下行的紧急数据的情况下，该小区网络设备指示某业务信道的信息传输方式为下行传输，相关小区(如相邻小区)内的基站也可以下发指示在该相关小区内的终端，在相同时间段内的业务信道的信息传输方式也为下行传输，这样可以避免相邻小区的终端由于在上行传输数据而对该需接收紧急数据的终端造成干扰。进一步的，还可以使相邻小区的基站也帮忙在业务信道中下发紧急数据，以提高紧急数据接收的成功率和效率。可选的，对非相邻小区但是对本小区的数据传输也会产生强干扰的小区，可以利用多接收天线技术抑制干扰。

在另一种实现方式下，网络设备可以根据终端在第三子帧之前的子帧中的上行请求信道上报的请求信息，或者网络设备根据业务需要或控制需要(例如电网中网络的控制设备要求该网络中的终端反应终端的工作状态或者终端的读数)，在第三子帧要求终端上报数据(紧急数据和普通数据中至少一种)，该第三子帧中的信息传输方式为上行传输。

对上述第三子帧，在指示的传输方式为上行传输和下行传输的情况下，该第三业务信道包括至少一个传输方式为下行传输的业务信道和至少一个传输方式为上行传输的业务信道，则在传输方式为上行传输的业务信道内，所述网络设备按照所述上行传输的信息传输方式，接收所述终端发送的数据；在传输方式为下行传输的业务信道内，所述网络设备按照所述下行传输的信息传输方式，向所述终端发送数据。具体的实现方式和说明可以参见前文的相关描述。

也就是说，可以规定在业务信道内包括多个对应不同的传输方式的时间段，网络设备可以通过在该子帧的下行紧急控制信道内发送的控制信息，告知终端准备相应的资源以在该子帧内的业务信道接收和发送信息，使得子帧结构更加灵活，减小了这部分数据的发送等待时间，从而减小这部分信息的时延。

。这样灵活的子帧结构可以用于需要在一个子帧内传输上行紧急数据和下行紧急数据的情况。在该情况下，进一步的，在不同的传顺方向的业务信道之间，还应包括间隔(类似前文提到的第一间隔或者第二间隔)，在该间隔内，网络设备与终端停止通信。

可选的，将上行的时间段(如上行请求信道和第二业务信道)放置在一起，将下行的时间段(如下行紧急控制信道和第一业务信道)放置在一起，可以减少所需的保护间隔，使子帧的利用率较高，子帧不至于被切割得太碎片化。

应当理解，在上文中提到的上行传输的业务信道可以供多个终端上传紧急数据，而下行传输的业务信道可以供网络设备给多个终端发送紧急数据。在一个业务信道中传输向多个终端的数据的情况下，会有一定的概率产生数据间的碰撞，也就是数据之间互相干扰。对普通数据，这种干扰可以容忍，而对于紧急数据，要求其传输的准确性，可以采用一些手段来减少这种干扰。可以采用一些手段防止不同传输方向的数据在同一子帧中传输而可能引起的碰撞，例如采用码分多址CDMA技术，或者不同的传输方向的数据使用不同的频点进行传输等。下面简单解释一下碰撞产生的情形，假设单个小区在T(ms)时间有N个终端要发上行紧急数据(每个终端在这段时间只有一次上报紧急数据的需求)，相邻的上行请求信道时间间隔为T_u，则这段时间总的上行请求信道个数为上行的紧急数据发生碰撞的概率为

同理，多个下行紧急数据在一个子帧传输也有发生碰撞的概率。

在上文中提到的第一间隔、第二间隔、第三间隔以及第四间隔，可以是全保护间隔(full GP，Guard Period)，用于避免上下行传输数据之间的干扰，保护数据传输的准确性。这是由于在TDD通信系统中，往往一个网络设备具有一定的覆盖范围，与多个终端进行通信，虽然理论上应该终端与网络设备的时间一致，而多个终端由于位置不同而各个设备对子帧中各信道对应的时间段的计算有偏差，也就是产生所谓的不同步问题，或者，为了达到同步，需要上传数据的终端会提前开始上传，故在子帧中数据的上下行切换时会干扰。而可选的，上述间隔是在该子帧的业务信道传输紧急数据的情况下存在的。因为紧急数据不仅对时延有较高要求，也需要尽量减少干扰以保证数据的准确性，因此牺牲了一部分子帧中通信的时间是值得的；而对于普通数据，由于对其传输的失真是可以允许的，而希望子帧中通信的时间尽量长，使用上述保护间隔就不是必要的，当然，对普通数据，使用这种间隔也是允许的。基于数据准确性(往往与系统的覆盖范围，如小区半径有关)和子帧通信时间的需求，可以得到不同的保护间隔取值。在一种实现方式下，保护间隔的长度设计时至少要考虑三个方面，(1)切换时间(2)信号在小区往返传输时延(3)数据处理时间。一般来说，切换时间固定(例如LTE系统可为40us)，小区往返时延和小区覆盖范围大小有关，数据处理时间和要传输的数据大小有关。举例来说，假如小区半径是60km，往返时延2*60*1000/300000000＝400us，那么GP大小必须大于400us+40us，因为还需留有数据处理时间。再比如，对于IoT 230的系统，最大支持小区半径100km的情况下，保护间隔长度可能要达到一个OFDM symbol长。

下面用一个示例来描述保护间隔的计算，该示例可以结合图6进行理解。图6用于说明本发明实施例中涉及的一种由于传输带来的数据干扰。例如图6中基站、终端1、终端2之间，以基站10点为基准时间，如果不加GP意味着帧结构中下行传输和上行传输之间是紧邻在一起的，即10点是下行结束的时间也是上行开始的时间。10点整基站给终端1传输的下行时间经过路径时延在10点02分到达终端1，t1＝2min。终端2为了保证自己的上行数据在10点整能够到达基站，必须提前考虑自己的路径时延，在9点59分就上传数据，t2＝1min。终端1一直处在接收数据状态，终端1就会在9点59分30秒收到终端1的数据，Dt＝0.5min。那么干扰时间就是9点59分30秒到10点02分，共计2.5min。所以为了避免干扰，只能延迟上行传输，即加上保护间隔。保护间隔至少为2.5min。应理解，此处的示意性说明是为了举例解释终端和网络设备由于位置不同带来的路径时延，而实际设置中，保护间隔的时长还需要考虑网络设备和终端进行切换数据传输方向所需的时间，以及网络设备或者终端处理接收到的数据的时间。因此，在这个例子中，保护间隔应当长于2.5min。

另一方面，在传输普通数据的子帧中，不同传输方向的信道之间，例如下行控制信道和信息传输方向为上行传输的业务信道，或者上行请求信道和信息传输方向为下行传输的业务信道之间，也可以存在间隔，这种间隔也可以称为小间隔(sGP,small GuardPeriod)，因此在上文中提到的第一间隔、第二间隔、第三间隔以及第四间隔，也可以是这种小间隔。这种小间隔是考虑了设备完成传输方向的切换所需的时间。事实上，数据由发变为收，发射机的功率不能马上消失，存在一个下降过程。同理，数据由收变为发，接收机把功率提上来也要时间。在LTE中，这两个时间的要求一样，通常要求不能超过20us。例如对于下行普通数据传输，如果该子帧内有上行请求信道，在下行的业务信道和上行请求信道之间需要留一个间隔，至少包括下行到上行切换时间，保证基站发完普通数据之后能够接收上行控制的数据。而基站接收完上行控制的数据之后，有可能需要在之后一个子帧的的下行紧急控制信道发送紧急数据传输通知，在收发之间也要有一个切换时间。在一个实施例中，可以将这两个切换时间设置在上行请求信道前的sGP中。也就是说，在一种实现方式下，在传输下行普通数据的子帧中，业务信道和上行请求信道之间的sGP至少包括上行到下行切换时间和下行到上行切换时间。

本发明实施例中说明了网络设备和终端间通信使用的多种子帧，它们还可以包括一些变体的结构。例如，一个子帧中还可以包括下行紧急控制信道和上行请求信道中的一个，或者说，多个子帧中还可以存在包括下行紧急控制信道和业务信道而不包括上行请求信道的第四子帧，该第四子帧中网络设备向发送的控制信息可以使得第四子帧后的至少一个子帧按照该控制信息所指示的。这样可以使得子帧的结构更加多样，更好地满足不同场景和系统下数据传输的低延时需要。

在上述提及的帧结构中，将下行紧急控制信道放置在子帧头，网络设备能够达到更好地控制该帧内与终端的数据传输的目的，而将上行请求信道放置在子帧尾或者倒数第二个OFDM，使终端能够更及时地向网络侧反馈该帧的数据传输情况，以及及时向网络侧发送上行紧急请求。

可选的，网络设备可以通过广播信道发送切换指令，该切换指令用于在该网络设备所在的网络中开启或者关闭本发明实施例所描述的子帧的传输。或者通过广播信道中的系统信息块(SIB,System Information Block)中的一个1bit来实现该指示指令的作用，该SIB可以是广播信道发送的小区信息的一部分。应理解，任何终端要接入小区，在取得同步后要接收一些小区信息，这些小区信息用于指示终端在该小区内与基站通信的配置，因此，系统中发送这些小区信息是时频位置和周期都是固定的，而这个过程往往是数据传输前的配置过程，故该SIB不会被终端当做数据。也就是说，网络设备可以在传输本发明实施例介绍的这种子帧结构和现有的帧结构中切换，使得本发明实施例所描述的这种子帧结构在现有的系统架构中的使用更加方便和灵活。例如由于网络系统中一部分新设备接入，或者网络系统中处理的业务种类的变化或者业务需求的变化，使得在某段时间内，系统中无需传输这种子帧结构。

下面为了便于理解，描述在一种实现方式下，网络设备通过下行紧急控制信道控制终端的过程。例如，在一种情况下，只在紧急数据传输的情况下在下行紧急控制信道发送控制信息，控制信息的具体实现可以是：使用一个指示符，当该指示符取一个特定值的时候，用于指示一子帧的业务信道要预留给下行紧急数据使用。比如网络设备在下行紧急控制信道发index 0(0被当做是特殊的值)，就说明有紧急下行数据要用该子帧。当该指示符取另一系列值的时候，根据小区中所有紧急终端的自身独有的身份证明(如SIM卡的ID，或者设备ID)给每个终端编号(UE-specific index)，比如编号之后为：终端1-终端N(假设有N个紧急终端)，如果下行紧急控制信道发index 1-N中的任一个，表示对应的终端要用该子帧传输其上行紧急数据。当该控制信息中携带该指示符的时候，如index字段，就说明没有紧急数据要传输。

下面以一个例子简单说明在使用上述指示符的情况下，网络设备与终端的如何交互，这种情况下，网络设备可以确定哪些是紧急终端哪些是普通终端(例如根据各终端部署的业务，各种终端的位置，各终端的种类等等)，紧急终端为有紧急数据要收发的终端，普通终端是没有紧急数据要收发的终端。每个子帧具有系统默认的信息传输方式，在有需求的情况下(例如有突发的紧急数据要传输)，可以通过下行紧急控制信道改变该子帧的信息传输方式。基站按照子帧的系统默认方式接收或发送数据，在数据传输的过程，每遇到上行紧急请求信道都要去检测一下有没有上行请求信息发过来，网络设备在一个子帧没有接到上行请求信息，则在该子帧的下一帧或者下下一帧的下行紧急控制信道不发任何index，这种情况下，该下一帧或者下下一帧若为下行子帧，则下行子帧中的下行紧急控制信道传输普通数据；若为上行子帧，则上行子帧中的下行紧急控制信道为空。同样大量普通终端(无紧急数据要收发的终端)按照每个子帧默认状态接收或发送相应的数据。在数据传输的过程，终端每遇到下行控制信道都要去检测一下其中的信息,发现基站没有发来任何的index，则表示没有紧急数据要传输，终端按照默认状态传输。所有紧急终端(有紧急数据要收发的终端)始终和系统保持在线连接，没有紧急数据需要接收或发送的时候，仍然在每个下行紧急控制信道检测一下其中的信息，检测到没有index发出，知道没有下行紧急数据要接收。

如果基站需要给某些终端发送紧急下行数据，基站侧在帧结构中最近的下行紧急控制信道发送index 0，并在该子帧的业务信道先给某个终端发调度信息和紧急下行数据。在终端侧，所有相关终端(包括所有紧急终端和正在传输的普通终端)在下行紧急控制信道检测信息，普通终端检测到有index(普通终端不用解出具体的index数值)，自己暂时中断数据传输；所有紧急终端检测到有index并且进一步解出具体是index 0,意识到自己可能需要在该子帧接收下行紧急数据。紧接着去该子帧对应的业务信道先解调度信息(因为紧急终端并不知道该子帧具体给哪个紧急终端用)，只有某一个或者几个紧急终端能成功解出调度信息，说明这个终端就要在该子帧接收下行数据，即根据基站所发的调度信息来决定继续接收对应紧急数据。没有在这一个子帧被调度的紧急终端，是基站另安排在其他子帧接收紧急数据，这些紧急终端在下一个子帧再去检测下行紧急控制信道中接收的信息。

如果紧急终端有紧急数据需要传输的时候，先在帧结构中最近的上行请求信道向基站发送请求信息(若有多个紧急终端需要传输可以一起发送)，这时候基站知道有哪些终端想要发送紧急数据。假设有3个终端都发了请求，它们身份证明对应的编号具体分别为2,10,15。

图7展示了在宽带系统和窄带系统中可采用的控制信息分布的示意图，图7中以传送上行紧急数据为例，故图7中所示的子帧由帧头到帧尾包括的不同填充图案的长方形依次表示：下行紧急控制信道，第一间隔，业务信道(上行)，上行请求信道，业务信道。进行例如，如果是宽带系统，可采用FDM的方式通知。比如将整个系统带宽分为三部分(implementation-dependent，具体可分成几部分看系统带宽，不够宽可能一个子帧频域上只够分2部分)，基站在子帧结构中最近的、时域上占下行紧急控制信道长、频域上分别占1/3频带(三段不同)的资源里分别发送三个终端的index。在终端侧，正在传输数据的普通终端在下行紧急控制信道检测到有index(普通终端不用解出具体的index数值)，则暂时中断数据传输；已经发送紧急上行请求的这些终端一直期望在下行紧急控制信道收到自己的index，因此在下行紧急控制信道重点检测自己的index，分别在不同频带上解出对应的index后在紧随的数据信道资源里传输紧急数据(时间上看三个终端是在一个子帧的)。如果是窄带系统，采用TDM的方式通知。基站在最近的下行紧急控制信道发送某一个具体终端的index(e.g.index 10)，可以看到，在TDM的方式中，可以在一个子帧内只通知一个紧急终端，这样有助于提高数据传输的准确率。在终端侧，正在传输的普通终端在下行紧急控制信道检测信息，检测到有index(普通终端不用解出具体的index数值)，暂时中断数据传输；已经发送紧急上行请求的这些终端自己知道期望在下行紧急控制信道收到自己的index，因此在下行紧急控制信道重点检测有没有自己的index,只有index 10的那个终端能成功解析(比如CRC通过)完整的控制信息，确定自己能在该子帧数据部分发送上行紧急数据。其他终端未接收到代表自己的index,则在下一个子帧继续接收。

综上，普通终端传输数据的时候遇到下行紧急控制信道都去接收信息，没有接收到带index的控制信息，则继续通信。检测到有index的控制信息，则暂时中断通信。紧急终端遇到下行紧急控制信道就去接收信息，在接收到有index的控制信息的情况下，紧急终端解析其中的index(已经发送过上行紧急请求的终端重点检查该index与自身的index是否匹配),如果检测到index 0,则去业务信道接收调度信息以及根据调度信息相应接收下行紧急数据，如果检测到对应自身的index则表示可以在该子帧业务信道上报紧急数据(前面已经上报过请求)。应理解，该实现方式只是一个例子，本发明实施例对如何实现控制信息以及如何根据控制信息进行通信均不作限定。

结合上述描述，可以认为，TDD通信系统的数据传输总是涉及上行数据传输和下行数据传输，而为了更好地控制传输过程，则引入了下行紧急控制信道以及上行请求信道，对不同的系统和场景，网络侧和终端侧可以使用不同的子帧结构，为了方便理解，以下结合图8和图9进行举例说明。图8描述了一种上行紧急数据传输的子帧结构中的交互流程，图9则描述了一种下行紧急数据传输的子帧结构中的交互流程。

如图8所示，一组终端中有终端有上行的紧急数据要传输，则待传输紧急数据的终端在一子帧的上行请求信道，通过上行请求信道向基站发送SR，基站接收了终端的SR,知道了终端有上行的紧急数据要发送。基站在下一子帧的下行紧急控制信道，通过下行控制信道向该组终端发送该子帧的具体配置(如业务信道的时长，指示可在业务信道进行上报等)，在该下行紧急控制信道接收到该具体配置后，该组中待上传普通数据的终端可根据该具体配置将网络资源(如信道)让出，以更好地保障待上传紧急数据的终端与基站的通信。在经过了保护间隔后，待上传紧急数据的终端在业务信道，通过上行数据信道承载紧急数据上传给基站，基站接收到该紧急数据后，进行解析以确认是否需要重传，若确认接收到的紧急数据正确则无需重传，基站在又下一子帧的下行紧急控制信道通过下行控制信道回复给上报数据的终端ACK，若确认接收到的紧急数据错误则需重传，基站在又下一子帧的下行紧急控制信道通过下行控制信道回复给上报数据的终端NACK，以及通知相应的终端在该又下一子帧的具体配置，以便这些终端在该又下一子帧中重传紧急数据，基站接收到重传的紧急数据后，将该重传的紧急数据与上一帧接收到的紧急数据一起解析，以确认是否需要重传，如果无需重传则回复ACK，如果仍然需要重传则在又下一子帧的下一子帧再次重复上述过程，直到无需重传或者达到重传次数的上限。

需要说明的是，关于上行的紧急数据传输之前要做的准备工作，比如先要通过上行随机接入过程与小区取得上行同步并建立连接，以及终端给基站发送上行参考信号让基站实时了解上行信道的质量等，上述过程不作赘述。

另一种场景下，如图9所示，基站有下行的紧急数据要传输，基站在一子帧的下行紧急控制信道向一组终端发送该子帧的具体配置(如业务信道的时长，通知将在业务信道下发紧急数据等)，以及在该子帧的业务信道向终端下发紧急数据，该组终端在该下行紧急控制信道接收到该具体配置后，其中无需接收紧急数据的终端可根据该具体配置将网络资源(如信道)让出，以更好地保障需接收紧急数据的终端与基站的通信。需接收紧急数据的终端解调接收到的下行数据，确定是否需要向基站发送重传请求，在解调成功的情况下无需重传，该终端在该子帧的上行请求信道，通过上行请求信道向基站发送ACK；在解调失败的情况下需要重传，该终端在该子帧的上行请求信道，通过上行请求信道向基站发送NACK和重传请求；需要重传的情况下，基站根据接收的NACK和重传请求，在下一子帧的下行紧急控制信道向待接收紧急数据的终端送该子帧的具体配置，以及在该子帧的业务信道向一组终端下发紧急数据，以便该组终端中需要重新接收紧急数据的终端在下行紧急控制信道接收该紧急数据，以及解调两次接收到的紧急数据，以确定是否需要再次重传，如果无需重传则回复ACK，如果仍然需要重传则在该下一子帧的下一子帧再次重复上述过程，直到无需重传或者达到重传次数的上限。

需要说明的是，关于下行的紧急数据传输之前要做的准备工作，比如如终端进行小区搜索，取得下行同步，获取小区的广播信息等过程等，上述过程不作赘述。

综上，通过在子帧中加入下行紧急控制信道以及上行请求信道，增强了对TDD协议下数据传输的控制，减少了一部分信息的发送等待时间，从而减小这部分信息的时延，使得TDD通信系统中的帧结构更加灵活，更适合传输紧急数据。进一步的，考虑网络设备与终端在收发数据过程中的硬件处理特点，合理地设计该下行紧急控制信道以及该上行请求信道的位置，以进一步减小数据的时延。并且在传输紧急数据的情况下，加入保护间隔，提高了数据传输的准确性，更符合紧急数据传输的低延时高准确率的要求。

综上，可以理解为，在子帧中插入下行紧急控制信道和上行请求信道可以降低数据的发送等待时间，从而减小这部分信息的时延，尤其是对紧急数据。优选的，可以采用本发明实施例中的子帧与现有技术的帧结构混用的方法传输数据，紧急数据优先占用本发明实施例中的子帧，而对普通数据使用现有技术的子帧结构和资源分配方式，这样能够更好地兼容现有的传输习惯，也避免了引入过多的下行紧急控制信道和上行请求信道，挤占业务信道而影响普通数据的传输。在这种情况下，下行紧急控制信道和上行请求信道插入的越密，就会将子帧分割为越多的小块，也会占用了更多本可以传输普通数据的资源，但是对于降低紧急数据的时延越好，在结合现有的TDD通信系统和帧结构使用本发明实施例的方法中，可以根据需要来设计帧结构中插入上述时间段和仅包括业务信道的子帧的比例。

以下结合图10和图11，以一个帧结构的长度为单位，以上文介绍过的IoT 230的系统帧为例，描述在该系统场景下，结合本发明实施例的方法对系统帧进行部分改进的通信过程，这种改进部分保留了IoT 230的系统帧的帧结构的形式，在现有的IoT 230系统中推广会更加容易。在该场景下，采用原IoT230系统中的一个帧为例来描述这种改进，为方便描述，称这种帧为改进帧。应理解，为了说明方便，图10和图11只示例性画出了一个子帧包括一种信息传输方式的业务信道的情况。

在图10中，示意终端与基站间使用通过时分双工(TDD)的帧来通信，原IoT230系统中的一个帧演化为了改进的帧结构。图10所示的帧结构中，下行基本结构(即下行子帧)的信息传输方式默认下行传输数据，上行基本结构(即上行子帧)的信息传输方式默认上行传输数据。一般情况下，普通数据的传输都可以按照默认的信息传输方式进行数据传输。图10中，没有改变默认设置的信息传输方式，将特殊子帧改为了下行子帧。图10中，放大描述的一个下行基本结构用于传输普通数据，这时，可以在下行紧急控制信道中传输下行的数据，在该下行基本结构中没有明确画出下行紧急控制信道，也就是说，从帧头到帧尾依次为业务信道，小间隔和上行请求信道。例如，上述实施例中的第二子帧，就可以具体是这种结构。图10中，放大描述的一个上行基本结构用于传输普通数据，这时，可以包括保护间隔或者小间隔(small guard period,sGP)，图10中包括的是保护间隔(full guard period,GP)，也就是说，从帧头到帧尾依次为下行紧急控制信道，保护间隔、业务信道和上行请求信道。

应理解，在一种情况下，某一个子帧的下行控制信道所发送的控制信息可以控制多个连续的子帧的信息传输状态。控制信息可用于指示在所述第一子帧的业务信道以及所述第一子帧接下来的至少一个子帧的业务信道的信息传输方式。这种情况下，所述第一子帧后接下来的至少一个子帧为该子帧后的至少一个连续的子帧，且，该至少一个连续的子帧中有一个子帧与第一子帧相邻。这种情况下，该第一子帧接下来的至少一个子帧中无需下行紧急控制信道。从而使得控制更加灵活，且提高子帧传输数据的利用率，降低子帧的开销(overhead)。

在紧急数据要传输的情况下，为了降低紧急数据的发送等待时间，从而减小这部分信息的时延，可以采用本发明实施例中的方法对图4中的帧的基本结构做一些改进，例如图10、图11所示。一种改进方式是，对原IoT230系统帧的每个子帧，都可以包括下行紧急控制信道和上行请求信道，可以保留前七个子帧是下行子帧，后7个子帧是上行子帧的结构，特殊子帧可以改换为下行或者上行子帧也可以不做处理，在传输普通数据时，子帧中可以包括上文中提到的sGP，长度为40us。图11中，示意了在一个帧中传输紧急数据的情况，其中涉及传输紧急数据的子帧结构，例如，该帧的第4个子帧和第14个子帧需要传输下行的紧急数据，其中第14个子帧的默认数据传输方式为上行传输，这两个子帧从帧头到帧尾依次为下行紧急控制信道、业务信道、保护间隔和上行请求信道。该子帧的第7个子帧和第11个子帧需要传输上行的紧急数据，其中第7个子帧的默认数据传输方式为上行传输，这两个子帧从帧头到帧尾依次为下行紧急控制信道、保护间隔、业务信道和上行请求信道。原特殊子帧，即第8个子帧，仍然改进为下行子帧。应理解，在一种实现方式下，为了保证紧急数据传输的准确性和资源的独占性，传输紧急数据的子帧中，中断普通数据的传输。

具体的，上行的紧急数据要在一下行子帧(一个IoT230系统帧的前七个子帧)中传输，该下行子帧中，下行紧急控制信道用于终端根据接收到的控制信息了解到当前子帧的结构发生了改变，在该下行子帧的业务信道，如果需要上传紧急数据(这类终端称为紧急终端)，则进行传输，以及在该下行子帧的下行紧急控制信道与业务信道之间有一保护间隔。具体从时序上来描述，要在下行子帧中传输上行紧急数据，终端应在从该下行子帧的前一子帧的再前一子帧的上行请求信道向基站发送SR,以通知基站将要发送上行紧急数据，则在该下行子帧中，基站在该子帧的下行紧急控制信道向一组终端广播控制信息，该组终端中普通终端(即在该下行子帧无需与基站传输紧急数据的终端)收到控制信息，让出资源以便紧急终端使用，即普通终端不在该子帧内接收该普通终端相应的数据，仅维持与基站的通信，普通终端与基站间的数据传输可以保持一个较低的速率，而网络设备接收不到该普通设备收到普通数据的ACK，会在后续的某个子帧再次下发普通终端需要接收的数据。也就可以理解为，普通终端在这种情况下，推迟接收该普通终端要接收的下行数据，紧急终端收到控制信息直接在业务信道传输上行紧急数据(不需要像普通数据那样先收基站通过下行控制信道PDCCH分配的上行资源PUSCH)。具体的，当下行紧急控制信道在帧头而上行请求信道在帧尾的情况下，上行紧急数据的时延为3个传输单元长度即3TTI,为24ms。

同理，下行的紧急数据在上行子帧(一个IoT230系统帧的后七个子帧)到来，上行子帧中，下行紧急控制信道用于终端根据在接收到的信息了解到当前子帧的结构发生了改变，在该上行子帧的业务信道，如果需要下传紧急数据(这类终端称为紧急终端)，则进行下行传输，该下行传输过程不需要基站通过下行调度PDCCH告诉终端数据使用哪个PDSCH传输而直接接收数据，而对于普通终端，由于没有上行的紧急数据要传输，在接收到控制信息后，让出资源以便紧急终端使用，以及在该上行子帧的上行请求信道与业务信道之间有一保护间隔。具体的，当下行紧急控制信道在帧头而上行请求信道在帧尾的情况下，下行的紧急数据的时延为2个传输单元长度即2个TTI,为16ms。

在一种实现方式下，在下行传输紧急数据的情况下，为了避免同小区的终端的干扰，基站会将整个小区在相同时间对应的业务信道的数据传输方式调成一致。甚至，为了避免相邻小区或者相关小区的干扰，几个相邻的基站会将几个相邻小区在相同时间对应的业务信道的数据传输方式调成一致。进一步的说明请参见前文中的相关段落，此处不再赘述。图12示意了在默认的上行子帧有终端要接收紧急的下行数据的情况。三个会互相影响的终端的在相同的一段时间(该相同的一段时间对应一个帧)中，在某一个默认的上行子帧，其中一个终端接收到控制信息，在该子帧内要接收紧急的下行数据，而另两个终端在该子帧是普通终端，则该三个终端对应的两个基站在该子帧的业务信道都发送下行的紧急数据以便该紧急终端接收，而另两个普通终端则停止发送普通数据。

相应的，在另一种实现方式下，在上行传输紧急数据的情况下，为了避免对同小区的终端造成干扰，基站会将整个小区在相同时间对应的业务信道的数据传输方式调成一致。甚至，为了避免干扰相邻小区或者相关小区，几个相邻的基站会将几个相邻小区在相同时间对应的业务信道的数据传输方式调成一致。进一步的说明请参见前文中的相关段落，此处不再赘述。图13示意了在默认的下行子帧有终端要上传紧急的上行数据的情况。三个会互相影响的终端的在相同的一段时间(该相同的一段时间对应一个帧)中，在某一个默认的下行子帧，其中一个终端在一个子帧上报请求，要求发送紧急的上行数据，则在该子帧之后的子帧(图示是第4子帧)，该紧急终端接收到控制信息，在该子帧内要发送紧急的上行数据，而另两个终端在该子帧是普通终端，则该三个终端对应的两个基站(其中一个基站与紧急终端在同一小区，另一个基站为能够接收到紧急终端数据的相关小区的基站)，在该子帧的业务信道都接收上行的紧急数据以进一步保证该紧急数据的传输，而另两个普通终端则停止发送普通数据。

另一方面，应当理解，图10和图11只是示例性说明，实际中，子帧的配置，例如业务信道的信息传输方式、包括什么样的间隔等，都是由下行紧急控制信道中的各种控制信息来确定的，图示的子帧排布方式对本发明实施例记载的方法和帧结构改进方案都不构成限定。例如，可以在一个子帧中包括多个业务信道，这多个业务信道可以具有不同的信息传输方式。

另一方面，由于改进的帧结构在应对数据的上下行传输需求的方面更加灵活，原IoT230系统帧的第八子帧即特殊子帧也可以用于传输上行或者下行的数据，基站在该特殊子帧的下行紧急控制信道向终端发送控制信息，告知终端该特殊子帧应如何进行通信即可，此处不再赘述。在特殊子帧中，不管是普通数据还是紧急数据传输，都有对应的传输结构适用，也就是说特殊子帧在本设计中没有任何特殊可言，就是一个改进的上行子帧或者下行子帧，这也是降低时延很重要的一方面。在后面的分析中，同样可以看出特殊传输单元和上下行传输单元结构的统一性。

在一种情况下，特殊子帧可以包括一特殊控制信道，基站或者网络中的控制设备可以在该特殊控制信道中使用广播的方式，通知终端使用或者停止使用改良子帧。也就是说，通过这种方式在现有的IoT230系统帧结构与改良子帧结构间切换，可以根据具体情况，如业务需求，组网结构变化等，进行控制，更加灵活方便，与现有的帧结构兼容。

上述过程的一种实现方式下，紧急数据可以和普通数据在同一子帧的业务信道进行传输，紧急数据在业务信道的前几个OFDM symbol传输(因为紧急数据的特点一般是小流量且数据量固定),该业务信道余下的OFDM symbol仍然可以用来传输普通的数据；另一方面，下行的紧急数据在下行子帧的业务信道传输的情况下，也与下行子帧传输普通数据是有不同的，基站在下行子帧的下行紧急控制信道发送控制信息，以通知终端当前子帧的具体配置(即在业务信道无需基站通过下行调度PDCCH告诉终端数据使用哪个PDSCH传输，而让紧急终端直接接收数据，以及加护了保护间隔GP)并在数据传输部分传输下行紧急数据。正在传输的普通终端收到控制信息让出资源给紧急终端用(即普通终端延迟收下行数据)，紧急终端收到控制信息直接在业务信道接收下行紧急数据。

另一方面，对于上下行紧急数据需要同时在一个子帧中传输的情况，也结合IoT230系统的场景做举例说明。可以在一个传输单元里包括两个信息传输方式。一般来说，紧急数据可以在几个OFDM symbol上发完，因此在同一个子帧里传输上行和下行的紧急数据是可以实现的，可以认为是该子帧包括两个业务信道，也可以认为是该子帧的业务信道包括两个子业务信道。靠近下行紧急控制信道的子业务信道传输下行的紧急数据，另一个子业务信道传输上行的紧急数据，具体的上下行数据传输的时长比例由基站在下行控制提前通知给终端，为了避免上下行之间的干扰，下行紧急数据和上行紧急数据之间需要加保护间隔GP。普通终端收到基站通知让出资源(即接收下行数据的普通终端延迟接收下行数据/发送上行数据的普通终端延迟发送上行数据)，紧急终端在对应的数据传输部分发送上行紧急数据(上行紧急终端)/接收下行紧急数据(下行紧急终端)。上下行紧急数据在同一个传输单元传输时，当下行紧急控制信道在帧头而上行请求信道在帧尾的情况下，上行时延为3个子帧长度即3TTI,为24ms，下行时延为2个子帧长度即2TTI,为16ms。

可见，IoT 230的系统帧的帧结构采用上述改进后，上行时延和下行时延都减小了，进一步的，加入保护间隔，也能够满足紧急数据的准确性要求。

下面结合图14，以一个具体的例子，描述使用一种改良帧结构后，对时延的影响。图14为在一帧中的部分子帧中插入下行紧急控制信道和上行请求信道，并使用这种改良帧结构进行数据传输的示意图。图10到图14只是示意，并不限定每个子帧都要包括下行紧急控制信道或者上行控制信道。

时延与上述两种信道插入的密度有关，要求时延低，插入就要密，子帧中的开销(overhead)就大，开销是指子帧中非业务信道所占子帧的时间。下面以一种TDD通信系统的帧结构为例，该TDD通信系统的帧结构中每个子帧长5ms，计算紧急数据的最大时延(即终端有上行紧急数据要发的时刻刚好错过能发上行紧急请求的信道；下行紧急数据到来的时刻刚好错过下行紧急控制信道，网络设备来不及在该下行紧急数据到来的时刻通知终端接收数据)。对该系统帧使用本发明实施例的改进方案，在一系统帧的每个子帧的子帧头(第一个OFDM符号)设置下行紧急控制信道，在每个子帧的子帧尾(最后一个OFDM符号)设置上行请求信道。一个该系统帧中包括15个子帧，其中第一到第五，第七以及第十四的默认设置为下行子帧。

如图14所示，在一下行子帧某终端有了需要给系统发送上行紧急数据，该终端在该下行子帧的上行请求信道发送紧急上行请求(SR)，隔一个子帧后，基站在该下行子帧的下下个子帧的下行紧急控制信道向终端发送控制信息，即通知终端子帧具体配置(即由下行基本结构变为上行紧急结构或数据传输由下行方向切换为上行方向)。普通终端在3号子帧(即图14中的第6个子帧)检测到没有自己的下行数据，不接收数据。紧急终端检测到自己在3号子帧发送紧急上行数据，在3号子帧中传输上行紧急数据。终端在下一子帧的下行紧急控制信道接收到网络设备的ACK或者NACK。插入间隔为5ms,则上行紧急数据时延为15ms。

在上行子帧需要给某终端传输下行紧急数据，基站在下一个子帧的下行紧急控制信道通知终端当前子帧具体配置(即由上行基本结构变成下行紧急结构或数据传输由上行方向切换为下行方向)，在子帧数据部分传输下行紧急数据。普通终端检测不到可以发上行数据的指示，不发送上行数据。紧急终端在业务信道检测到到下行紧急数据是发送给自己的，接收该下行紧急数据，紧急终端在该子帧的上行控制信道回复ACK或者NACK。插入间隔为5ms，则下行紧急数据时延为10ms。事实上，紧急数据传输保证高可靠，一般一次性就能传输成功，上行或者下行紧急数据传输后，发送端都会关注接收端的ACK和NACK信息。

另一方面，图14对应的实施例的TD-LTE系统的改良子帧(子帧长5ms)的业务信道里可以包括多个子业务信道，该多个业务子信道可以被该子帧的下行紧急控制信道设置为不同的信息传输方向，则上行数据和下行数据可以在一个子帧中传输。同样每个子帧的子帧头(第一个OFDM符号)设置下行紧急控制信道，在每个子帧的子帧尾(最后一个OFDM符号)设置上行请求信道。在这种情况下，上行紧急数据时延为15ms，下行紧急数据时延为10ms。

应当理解，如果该帧没有进行改良，则在一子帧中，终端与基站需要传输与该子帧的默认信息传输方式不同的数据(紧急数据或普通数据)，必须要等待到具有合适的信息传输方式的子帧，上下行数据的发送等待时间长，显然时延也较长。

时延和上下行控制信道的插入密度有关，在上述的参数设置下，overhead为对应一次性传输紧急数据成功和紧急数据经过两次传输传输成功的时延如下表1所示，表1中还列出当改变子帧结构设计的参数，使overhead为上述例子中的两倍的时候，对应一次性传输紧急数据成功和紧急数据经过两次传输传输成功的时延。

表1

将上行请求信道设置在子帧的倒数第二个正交分频复用OFDM符号(symbol)，可以减小上行的数据(尤其是紧急数据)的时延。同样是以图8对应的TD-LTE的一种系统帧为例，在另一个实施例中，对这种系统帧的改进可参看上文图8对应的实施例，唯独不同的是在每个子帧中，上行请求信道位于子帧的倒数第二个正交分频复用OFDM符号(symbol)，而下行紧急控制信道仍然位于子帧的第一个正交分频复用OFDM符号(symbol)。这种方案下，在某下行子帧中，某终端产生了需要给基站发送的上行的紧急数据，该终端在该下行子帧的上行请求信道发送请求信息，由于该下行子帧的上行请求信道和该下行子帧的下一子帧的下行紧急控制信道间，相隔至少1个OFDM符号，基站可以在这段时间内收到该终端发送的请求信息，以便基站可以在该下行子帧的下一子帧下行紧急控制信道通知终端在该下一子帧中上传该上行的紧急数据，该下一子帧原本是下行子帧(例如通知终端该下行子帧的由下行传输切换为上行传输，以及配置相应的保护间隔)，以及在该下一子帧的业务信道接收紧急终端上传的紧急数据。普通终端检测到自己要接收的普通数据，不接收数据。紧急终端检测到自己可以发送紧急上行数据，在业务信道传输上行紧急数据。则若子帧长度5ms,每个子帧都有上行请求信道和下行紧急控制信道，上行紧急数据时延为10ms。

类似的，在某上行子帧中，基站获得了需要给终端发送的下行的紧急数据，该上行子帧的下一子帧的默认配置为上行子帧，基站在该下一个子帧的下行紧急控制信道下发控制信息，(例如通知终端该上行子帧的由上行传输切换为下行传输，以及配置相应的保护间隔)，在该下一子帧的业务信道传输下行紧急数据。若子帧长度5ms,每个子帧都有下行紧急控制信道，下行紧急数据时延为10ms。也就是说，这种情况与图8对应的子帧结构的下行紧急数据的时延相等。

可见，这种实现方式下并没有改变整个上下行控制信道插入的密度，overhead并没有发生变化。由于上行控制和下行控制之间相相隔一个OFDM符号，在一子帧的上行请求信道发送完上行紧急请求之后，不用等一个子帧，基站有时间完成下行到上行之间的切换以及处理上行紧急请求，可以下一个子帧的下发控制信息并在该子帧接收终端发送的紧急数据，和图8对应的实施例相比节省了上行紧急数据一个子帧的时延。一次性传输紧急数据成功和紧急数据经过两次传输传输成功的时延如下表2所示，表2中还列出当改变子帧结构设计的参数，使overhead变为两倍的时候，对应一次性传输紧急数据成功和紧急数据经过两次传输传输成功的时延。

表2

下面结合图15描述本发明实施例记载的一种网络设备1500。该网络设备1500可以用于执行上述图5到图14对应的实施例中的任意一种方法。该网络设备1500用于在时分双工TDD通信系统中通过多个子帧传输信息,该时分双工TDD通信系统包括网络设备与终端，该多个子帧包括第一子帧，所述第一子帧包括第一业务信道和第一上行请求信道，该网络设备1500包括：数据传输模块1501，所述数据传输模块1501用于通过所述第一业务信道与所述终端传输数据；

请求接收模块1502，用于通过所述第一上行请求信道，接收所述终端的上报信息，所述上报信息为第二业务的数据传输请求、第三业务的数据和预设的紧急指令的反馈消息中的至少一种，所述第二业务和所述第三业务为预设的紧急业务。

这样，可以通过该第一上行请求信道，将紧急业务的请求、数据和预设的紧急指令的反馈消息上报给网络设备，在一个子帧中有业务信道和上行请求信道，给紧急业务和紧急指令的反馈消息预留了资源，使得这些上报信息可以及时而灵活地上报，而不需要等待到正在传输的数据发完，在传输方向合适的子帧进行传输，从而减小了这部分对时延要求的较高的上报信息的发送等待时间，从而减小这部分信息的时延。

。在一种实现方式下，所述第一子帧为下行子帧，所述第一子帧还包括第一间隔，并且所述第一间隔与所述第一上行请求信道相邻，在所述第一间隔内，所述网络设备与所述终端停止通信，在通过所述第一业务信道与所述终端传输第一业务的数据的方面，所述数据传输模块1501用于：所述网络设备通过所述第一业务信道向所述终端发送第一业务的数据。这样，该第一间隔可以避免该网络设备与该终端在第一子帧传输的数据不被该网络设备所在小区内的其他终端干扰。

在一种实现方式下，所述多个子帧还包括第二子帧，所述第二子帧在所述第一子帧之后，所述上报信息包括所述第二业务的数据传输请求，所述第二子帧包括第二下行紧急控制信道和第二业务信道，所述网络设备还包括传输控制模块1503，所述传输控制模块1503用于根据所述第二业务的数据传输请求，通过所述第二下行紧急控制信道向所述终端发送第二控制信息，所述第二控制信息用于指示在所述第二业务信道内，所述网络设备与所述终端之间的信息传输方式为上行传输；所述数据传输模块1501还用于通过所述第二业务信道，接收所述终端发送的所述第二业务的数据。

在一种实现方式下，所述传输控制模块1503还用于通过所述第二下行紧急控制信道向所述终端发送数据。这样，下行紧急控制信道也可以用于传递数据，充分利用了子帧的信道资源，使一个子帧中用于传输数据时间尽可能长。

在一种实现方式下，所述多个子帧还包括第三子帧，所述第三子帧包括第三下行紧急信道、第三业务信道以及第三上行请求信道，所述第三下行紧急信道在所述第三业务信道以及所述第三上行请求信道之前，所述传输控制模块1503还用于通过所述第三下行紧急控制信道向所述终端发送第三控制信息，所述第三控制信息用于指示在所述第三子业务信道内，所述网络设备与所述终端间的信息传输方式，所述信息传输方式为上行传输或者下行传输；所述数据传输模块1501还用于通过所述第三业务信道，使用所述信息传输方式与所述终端进行通信；所述请求接收模块1502还用于通过所述第三上行请求信道，接收所述终端的上报信息，所述上报信息为第四业务的数据传输请求、第五业务的数据和预设的紧急指令的反馈消息中的至少一种，所述第四业务和所述第五业务为预设的紧急业务,所述第三上行请求信道仅用于传输所述上报信息。

综上，通过在子帧中加入下行紧急控制信道以及上行请求信道，增强了对TDD协议下数据传输的控制，减小了一部分信息的发送等待时间，从而减小这部分信息的时延，使得TDD通信系统中的帧结构更加灵活，更适合传输紧急数据。进一步的，考虑网络设备与终端在收发数据过程中的硬件处理特点，合理地设计该下行紧急控制信道以及该上行请求信道的位置，以进一步减小信息的发送等待时间。并且在传输紧急数据的情况下，加入保护间隔，提高了数据传输的准确性，更符合紧急数据传输的低延时高准确率的要求。

应当理解，图15对应的实施例中所提及的各模块只是一个功能性的区分，可能之间有互相包括或者重叠的部分，在实际的产品中，网络设备还可以包括其他的软硬件模块。例如，传输控制模块1503主要是下发消息，请求接收模块1502主要是接收请求，而数据传输模块1501可以发送和接收数据，而实际产品中，数据和消息可以采用同一套硬件或者模块进行收发，则数据传输模块1501对应的器件可以就是请求接收模块1502和传输控制模块1503对应的器件。在一种实现方式下，请求接收模块1502、传输控制模块1503和数据传输模块1501中的发送和接收功能，可以由通信接口，例如收发器实现，在网络设备为基站的情况下，硬件可以对应基站的收发台。在网络设备为路由器、网关或者服务器的情况下，硬件可以对应射频电路，其中包括天线等器件。本发明实施例对请求接收模块1502、传输控制模块1503和数据传输模块1501的实现方式不做限定。

下面结合图16描述本发明实施例记载的一种终端1600。该终端1600可以用于执行上述图4到图14对应的实施例中的任意一种方法。该终端用于在时分双工TDD通信系统中通过多个子帧传输信息,所述多个子帧包括第一子帧，所述第一子帧包括第一业务信道和第一上行请求信道，所述终端包括：数据传输模块1601，用于通过所述第一业务信道与所述网络设备传输第一业务的数据；请求上报模块1602，用于通过所述第一上行请求信道，向所述网络设备发送上报信息，所述上报信息为第二业务的数据传输请求、第三业务的数据和预设的紧急指令的反馈消息中的至少一种，所述第二业务和所述第三业务为预设的紧急业务。这样，可以通过该第一上行请求信道，将紧急业务的请求、数据和预设的紧急指令的反馈消息上报给网络设备，在一个子帧中有业务信道和上行请求信道，给紧急业务和紧急指令的反馈消息预留了资源，使得这些上报信息可以及时而灵活地上报，而不需要等待到正在传输的数据发完，在传输方向合适的子帧进行传输，从而减小了这部分对时延要求的较高的上报信息的发送等待时间，从而减小了这部分上报信息的时延。

在一种实现方式下，所述第一子帧为下行子帧，所述第一子帧还包括第一间隔，并且所述第一间隔与所述第一上行请求信道相邻，在所述第一间隔内，所述网络设备与所述终端停止通信,在通过所述第一业务信道与所述网络设备传输第一业务的数据,所述数据传输模块1601用于通过所述第一业务信道接收所述网络设备发送的第一业务的数据。这样，该第一间隔可以避免该网络设备与该终端在第一子帧传输的数据不被该网络设备所在小区内的其他终端干扰。

在一种实现方式下，所述多个子帧还包括第二子帧，所述第二子帧在所述第一子帧之后，所述上报信息包括所述第二业务的数据传输请求，所述第二子帧包括第二下行紧急控制信道和第二业务信道，所述终端还包括控制接收模块1603，所述控制接收模块1603用于接收来自所述网络设备的第二控制信息,所述第二控制信息用于指示在所述第二业务信道内，所述网络设备与所述终端之间的信息传输方式为上行传输；所述数据传输模块1601还用于通过所述第二业务信道，向所述网络设备上报所述第二业务的数据。

在一种实现方式下，所述控制接收模块1603还用于通过所述第二下行紧急控制信道接收来自所述网络设备的数据。这样，下行紧急控制信道也可以用于传递数据，充分利用了子帧的信道资源，使一个子帧中用于传输数据时间尽可能长。

在一种实现方式下，所述多个子帧还包括第三子帧，所述第三子帧包括第三下行紧急信道、第三业务信道以及第三上行请求信道，所述第三下行紧急信道在所述第三业务信道以及所述第三上行请求信道之前，所述控制接收模块1603还用于通过所述第三下行紧急控制信道接收来自所述网络设备的第三控制信息，所述第三控制信息用于指示在所述第三业务信道内，所述网络设备与所述终端间的信息传输方式，所述信息传输方式为上行传输或者下行传输；

所述数据传输模块1601还用于通过所述第三业务信道，使用所述信息传输方式与所述终端进行通信；所述请求上报模块1602还用于通过所述第三上行请求信道，向所述网络设备发送上报信息，所述上报信息为第四业务的数据传输请求、第五业务的数据和预设的紧急指令的反馈消息中的至少一种，所述第四业务和所述第五业务为预设的紧急业务,所述第三上行请求信道仅用于传输所述上报信息。

对上述图15对应的实施例所描述的网络设备和图16对应的实施例所描述的终端之间所传输的第一子帧，在一种实现方式下，所述第一上行请求信道为所述第一子帧的倒数第二个正交分频复用OFDM符号(symbo l)。这样，如果终端在该第一上行请求信道中要求向网络设备上报紧急数据，在第一子帧的下一个子帧，网络设备就可以告诉终端，该下一个子帧可以上报数据，从而减少终端上报数据的时延。

对上述图15对应的实施例所描述的网络设备和图16对应的实施例所描述的终端之间所传输的第一子帧，在一种实现方式下，所述第一上行请求信道仅用于传输所述上报信息。这样，就可以保证上报信息有专用的信道传输，不会被普通数据占据资源，由于上报信息为与紧急业务以及紧急指令相关的信息，从而保证上报信息的传输，减小上报信息的发送等待时间，从而减小上报信息的时延。

对上述图15对应的实施例所描述的网络设备和图16对应的实施例所描述的终端之间所传输的第一子帧，在一种实现方式下，所述第二子帧还包括第二间隔，所述第二间隔位于所述第二业务信道与所述第二下行紧急控制信道之间，在所述第二间隔内，所述网络设备与所述终端停止通信。在一种实现方式下，该第二间隔在该业务信道之前且与该业务信道相邻。该第二间隔可以避免该网络设备与该终端在第一子帧传输的数据不被该网络设备所在小区内的其他终端干扰。

以及，在图15对应的实施例所描述的网络设备和图16对应的实施例所描述的终端之间所传输的子帧中，有了下行紧急控制信道，网络设备和终端传输数据就更加灵活，如果需要，在每个子帧网络侧都可以与终端协商数据传输的方式，这一作用在紧急数据传输的时候尤其重要，因为普通数据会按照协议中规定的默认的数据传输状态传输，而如果在普通数据的传输过程中，突然有与普通数据流向不同的紧急数据需要传输，网络侧必须提前在下行紧急控制信道上通知终端当前传输单元的配置变化，才能协调紧急数据和普通数据传输。下行紧急控制信道还可以用于网络侧向终端发送对应上一个子帧的上行传输过程的ACK(Acknowledgement，确认字符)/NACK(Negative Acknowledgment,否定回答)。

以及，在一种情况下，图15对应的实施例所描述的网络设备和图16对应的实施例所描述的终端之间所传输的第一子帧中的控制信息可以控制连续的多个子帧的信息传输方式。该控制信息用于指示在所述第一子帧的业务信道以及所述第一子帧接下来的至少一个子帧的业务信道的信息传输方式。这种情况下，所述第一子帧后接下来的至少一个子帧为该子帧后的至少一个连续的子帧，且，该至少一个连续的子帧中有一个子帧与第一子帧相邻。这种情况下，该第一子帧接下来的至少一个子帧中无需下行紧急控制信道。从而使得控制更加灵活，且提高子帧传输数据的利用率，降低子帧的开销。

以及，在一种实现方式下，图15对应的实施例所描述的网络设备和图16对应的实施例所描述的终端之间所传输的第三子帧，该第三子帧的所述第三上行请求信道为所述第三子帧的倒数第二个正交分频复用OFDM符号(symbo l)。这样，终端和网络设备可以在该第二子帧的最后一个OFDM符号的时间内做好准备，使得在第三子帧的后一个子帧，终端就可以上报数据，进一步减小了上报数据的时延。

综上，通过在子帧中加入下行紧急控制信道以及上行请求信道，增强了对TDD协议下数据传输的控制，减小了数据的发送等待时间，从而减小数据的时延，使得TDD通信系统中的帧结构更加灵活，更适合传输紧急数据。进一步的，考虑网络设备与终端在收发数据过程中的硬件处理特点，合理地设计该下行紧急控制信道以及该上行请求信道的位置，以进一步减小数据的时延。并且在传输紧急数据的情况下，加入保护间隔，提高了数据传输的准确性，更符合紧急数据传输的低延时高准确率的要求。

应当理解，图16对应的实施例中所提及的各模块只是一个功能性的区分，可能之间有互相包括或者重叠的部分，在实际的产品中，终端还可以包括其他的软硬件模块。例如，控制接收模块1603主要是接收消息，请求上报模块1602主要是发送信息，而数据传输模块1601可以发送和接收数据，而实际产品中，数据和消息可以采用同一套硬件或者模块进行收发，也就是则数据传输模块1601对应的器件可以就是控制接收模块1603和请求上报模块1602对应的器件。在一种实现方式下，控制接收模块1603、请求上报模块1602和数据传输模块1601中的发送和接收功能，可以由通信接口，例如收发器实现，例如可以是终端的调制解调器中的程序控制射频电路(包括天线等器件)实现。本发明实施例对控制接收模块1603、请求上报模块1602和数据传输模块1601的实现方式不做限定。

对图15对应的实施例所描述的网络设备和图16对应的实施例所描述的终端，以及二者之间传输的子帧的进一步说明的相关内容，请参照说明书前文的描述，这里不再赘述。

本发明实施例还提供一种装置，以实现上述各个方法实施例中的方法。该装置的结构示意图，如图17所示。应理解，图17所示的示意图，可以适用于该方法中的网络设备，也可以适用于上述方法中的终端。该装置用于在时分双工TDD通信系统中通过多个子帧传输信息,所述时分双工TDD通信系统包括所述网络设备与终端，所述多个子帧包括第一子帧，所述第一子帧包括第一业务信道和第一上行请求信道。该装置包括处理电路1702，以及与其连接的通信接口1704。在一些情况下，还可以包括存储介质1706。

其中，处理电路1702用于处理数据，控制数据访问和存储，发出命令以及控制其它设备执行操作。处理电路1702可以被实现为一个或多个处理器，一个或多个控制器和/或可用于执行程序等的其它结构。处理电路1702具体可以包括通用处理器，数字信号处理器(DSP)，专用集成电路(ASIC)，现场可编程门阵列(FPGA)或其它可编程逻辑组件中的至少一种。应理解，在处理电路302为专用集成电路(ASIC)，现场可编程门阵列(FPGA)或其它可编程逻辑组件的情况下，存储介质1704可以与处理电路1702集成在一起。通用处理器可以包括微处理器，以及任何常规的处理器，控制器，微控制器，或状态机。处理电路1702也可以实现为计算组件，例如DSP和微处理器的组合。

在一种实现方式下，该装置1700为一种智能终端，如手机，该终端的处理电路包括应用处理器1709和传输处理器1710。

应理解，图17所示的只是一种实现方式下的示意图，这种情况下，该装置中具有独立于处理电路1702存在的存储介质(例如存储器)，存储介质与处理电路1702以及通信接口1704可以通过总线连接。例如服务器、手机终端等都适用这种情况，然而，应理解，在另一种实现方式下，处理电路1702为专用集成电路(ASIC)，现场可编程门阵列(FPGA)或其它可编程逻辑组件，存储介质可以与处理电路302集成在一起，与图中所示有所区别，例如一些路由器、网关、电力系统中的一些设备如电表等，就可以采取这种实现，本发明实施例不做限定。

存储介质1706可以包括计算机可读存储介质，如磁存储设备(例如，硬盘，软盘，磁条)，光存储介质(例如，数字多功能盘(DVD))，智能卡，闪存设备，随机存取存储器(RAM)，只读存储器(ROM)，可编程ROM(PROM)，可擦除PROM(EPROM)，寄存器，以及它们的任意组合。存储介质1706可以耦合到处理电路1702以使得处理电路1702可读取信息和将信息写入到存储介质1706。具体地，存储介质1706可以集成到处理电路1702，或者存储介质1706和处理电路1702可以是分开的。

通信接口1704可包括电路和/或程序以实现用户设备与一个或多个无线网络设备(例如，基站、服务器等)之间的双向通信。例如通信接口1704可以是收发器，收发器可以包括一组具有接收功能的器件(如包括一组接口、一组天线和接收电路1716中的至少一个)，以及一组具有发送功能的器件(如另一组接口、一组天线和发射电路1718中的至少一个)；也可以是一组兼具接收功能和发送功能的器件(如一组接口或者一组天线)。一种实现方式下，通信接口1704可以耦合到一个或多个天线(图17中未示出)，并包括至少一个接收电路1716和/或至少一个发射电路1718。

图17所示的装置，在一种实现方式下，可以是网络设备，该网络设备可以通过处理电路1702执行程序，以调用通信接口1704，实现本发明上述的方法实施例中网络设备所执行的方法。可以理解的是，图15对应的实施例中的网络设备的请求接收模块1502、传输控制模块1503和数据传输模块1501，可以是由处理电路302调用通信接口304实现的。关于该装置为网络设备执行本发明方法实施例中的方法的细节以及技术效果，请参看前文，此处不再赘述。

图17所示的装置，还可以是终端，该终端可以通过处理电路1702执行程序，以调用通信接口1704，实现本发明上述的方法实施例中终端执行的方法。可以理解的是，图16对应的实施例中的终端的控制接收模块1603、请求上报模块1602和数据传输模块1601，可以是由处理电路1702调用通信接口1704实现的。关于该装置为终端执行本发明方法实施例中的方法的细节以及技术效果，请参看前文，此处不再赘述。

以上对本发明实施例所提供的传输信息的方法、网络设备及终端进行了详细介绍，本文中应用了多个实施例对本发明的原理及实施方式进行了阐述，同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。

Claims (34)

1.一种信息传输方法，所述传输方法用于在时分双工TDD通信系统中通过多个子帧传输信息,所述时分双工TDD通信系统包括网络设备与终端，其特征在于，所述多个子帧包括第一子帧，所述第一子帧包括第一业务信道和第一上行请求信道，所述传输方法包括：

所述网络设备通过所述第一业务信道与所述终端传输数据；

所述网络设备通过所述第一上行请求信道，接收所述终端的上报信息，所述上报信息为第二业务的数据传输请求、第三业务的数据和预设的紧急指令的反馈消息中的至少一种，所述第二业务和所述第三业务为预设的紧急业务。

2.根据权利要求1所述的方法，其特征在于，所述第一子帧为下行子帧，所述第一间隔与所述第一上行请求信道相邻所述第一子帧还包括第一间隔，并且所述第一间隔与所述第一上行请求信道相邻，在所述第一间隔内，所述网络设备与所述终端停止通信，所述网络设备通过所述第一业务信道与所述终端传输第一业务的数据，包括：

所述网络设备通过所述第一业务信道向所述终端发送第一业务的数据。

3.根据权利要求1或2所述的方法，其特征在于，所述第一上行请求信道为所述第一子帧的倒数第二个正交分频复用OFDM符号(symbol)。

4.根据权利要求1到3任一权利要求所述的方法，其特征在于,所述第一上行请求信道仅用于传输所述上报信息。

5.根据权利要求1到4任一权利要求所述的方法，其特征在于，所述多个子帧还包括第二子帧，所述第二子帧在所述第一子帧之后，所述上报信息包括所述第二业务的数据传输请求，所述第二子帧包括第二下行紧急控制信道和第二业务信道，所述方法还包括：

所述网络设备根据所述第二业务的数据传输请求，通过所述第二下行紧急控制信道向所述终端发送第二控制信息，所述第二控制信息用于指示在所述第二业务信道内，所述网络设备与所述终端之间的信息传输方式为上行传输；

所述网络设备通过所述第二业务信道，接收所述终端发送的所述第二业务的数据。

6.根据权利要求5所述的方法，其特征在于，所述第二子帧还包括第二间隔，所述第二间隔位于所述第二业务信道与所述第二下行紧急控制信道之间，在所述第二间隔内，所述网络设备与所述终端停止通信。

7.根据权利要求5或6任一权利要求所述的方法，其特征在于，所述方法还包括：所述网络设备通过所述第二下行紧急控制信道向所述终端发送数据。

8.根据权利要求1到7任一权利要求所述的方法，其特征在于，所述多个子帧还包括第三子帧，所述第三子帧包括第三下行紧急信道、第三业务信道以及第三上行请求信道，所述第三下行紧急信道在所述第三业务信道以及所述第三上行请求信道之前，所述方法包括：

所述网络设备通过所述第三下行紧急控制信道向所述终端发送第三控制信息，所述第三控制信息用于指示在所述第三子业务信道内，所述网络设备与所述终端间的信息传输方式，所述信息传输方式为上行传输或者下行传输；

所述网络设备通过所述第三业务信道，使用所述信息传输方式与所述终端进行通信；

所述网络设备通过所述第三上行请求信道，接收所述终端的上报信息，所述上报信息为第四业务的数据传输请求、第五业务的数据和预设的紧急指令的反馈消息中的至少一种，所述第四业务和所述第五业务为预设的紧急业务,所述第三上行请求信道仅用于传输所述上报信息。

9.一种信息传输方法，所述传输方法用于在时分双工TDD通信系统中通过多个子帧传输信息,所述时分双工TDD通信系统包括网络设备和终端，其特征在于，所述多个子帧包括第一子帧，所述第一子帧包括第一业务信道和第一上行请求信道，所述传输方法包括：

所述终端通过所述第一业务信道与所述网络设备传输第一业务的数据；

所述终端通过所述第一上行请求信道，向所述网络设备发送上报信息，所述上报信息为第二业务的数据传输请求、第三业务的数据和预设的紧急指令的反馈消息中的至少一种，所述第二业务和所述第三业务为预设的紧急业务。

10.根据权利要求9所述的方法，其特征在于，所述第一子帧为下行子帧，所述第一间隔与所述第一上行请求信道相邻所述第一子帧还包括第一间隔，并且所述第一间隔与所述第一上行请求信道相邻，在所述第一间隔内，所述网络设备与所述终端停止通信,所述终端通过所述第一业务信道与所述网络设备传输第一业务的数据,包括:

所述终端通过所述第一业务信道接收所述网络设备发送的第一业务的数据。

11.根据权利要求9或10所述的方法，其特征在于，所述第一上行请求信道为所述第一子帧的倒数第二个正交分频复用OFDM符号(symbol)。

12.根据权利要求9到11任一权利要求所述的方法，其特征在于,所述第一上行请求信道仅用于传输所述上报信息。

13.根据权利要求9到12任一权利要求所述的方法，其特征在于，所述多个子帧还包括第二子帧，所述第二子帧在所述第一子帧之后，所述上报信息包括所述第二业务的数据传输请求，所述第二子帧包括第二下行紧急控制信道和第二业务信道，所述方法还包括：

所述终端接收来自所述网络设备的第二控制信息,所述第二控制信息用于指示在所述第二业务信道内，所述网络设备与所述终端之间的信息传输方式为上行传输；

所述终端通过所述第二业务信道，向所述网络设备上报所述第二业务的数据。

14.根据权利要求13所述的方法，其特征在于，所述第二子帧还包括第二间隔，所述第二间隔位于所述第二业务信道与所述第二下行紧急控制信道之间，在所述第二间隔内，所述网络设备与所述终端停止通信。

15.根据权利要求13或14任一权利要求所述的方法，其特征在于，所述方法还包括：所述终端通过所述第二下行紧急控制信道接收来自所述网络设备的数据。

16.根据权利要求9到15任一权利要求所述的方法，其特征在于，所述多个子帧还包括第三子帧，所述第三子帧包括第三下行紧急信道、第三业务信道以及第三上行请求信道，所述第三下行紧急信道在所述第三业务信道以及所述第三上行请求信道之前，所述方法包括：

所述终端通过所述第三下行紧急控制信道接收来自所述网络设备的第三控制信息，所述第三控制信息用于指示在所述第三业务信道内，所述网络设备与所述终端间的信息传输方式，所述信息传输方式为上行传输或者下行传输；

所述终端通过所述第三业务信道，使用所述信息传输方式与所述终端进行通信；

所述终端通过所述第三上行请求信道，向所述网络设备发送上报信息，所述上报信息为第四业务的数据传输请求、第五业务的数据和预设的紧急指令的反馈消息中的至少一种，所述第四业务和所述第五业务为预设的紧急业务,所述第三上行请求信道仅用于传输所述上报信息。

17.一种网络设备，所述网络设备用于在时分双工TDD通信系统中通过多个子帧传输信息,所述时分双工TDD通信系统包括网络设备与所述终端，其特征在于，所述多个子帧包括第一子帧，所述第一子帧包括第一业务信道和第一上行请求信道，所述网络设备包括：

数据传输模块，用于通过所述第一业务信道与所述终端传输数据；

请求接收模块，用于通过所述第一上行请求信道，接收所述终端的上报信息，所述上报信息为第二业务的数据传输请求、第三业务的数据和预设的紧急指令的反馈消息中的至少一种，所述第二业务和所述第三业务为预设的紧急业务。

18.根据权利要求17所述的网络设备，其特征在于，所述第一子帧为下行子帧，所述第一间隔与所述第一上行请求信道相邻所述第一子帧还包括第一间隔，并且所述第一间隔与所述第一上行请求信道相邻，在所述第一间隔内，所述网络设备与所述终端停止通信，在通过所述第一业务信道与所述终端传输第一业务的数据的方面，所述数据传输模块用于：所述网络设备通过所述第一业务信道向所述终端发送第一业务的数据。

19.根据权利要求17或18所述的网络设备，其特征在于，所述第一上行请求信道为所述第一子帧的倒数第二个正交分频复用OFDM符号(symbol)。

20.根据权利要求17到19任一权利要求所述的网络设备，其特征在于,所述第一上行请求信道仅用于传输所述上报信息。

21.根据权利要求17到20任一权利要求所述的网络设备，其特征在于，所述多个子帧还包括第二子帧，所述第二子帧在所述第一子帧之后，所述上报信息包括所述第二业务的数据传输请求，所述第二子帧包括第二下行紧急控制信道和第二业务信道，所述网络设备还包括传输控制模块，所述传输控制模块用于根据所述第二业务的数据传输请求，通过所述第二下行紧急控制信道向所述终端发送第二控制信息，所述第二控制信息用于指示在所述第二业务信道内，所述网络设备与所述终端之间的信息传输方式为上行传输；

所述数据传输模块还用于通过所述第二业务信道，接收所述终端发送的所述第二业务的数据。

22.根据权利要求21所述的网络设备，其特征在于，所述第二子帧还包括第二间隔，所述第二间隔位于所述第二业务信道与所述第二下行紧急控制信道之间，在所述第二间隔内，所述网络设备与所述终端停止通信。

23.根据权利要求21或22任一权利要求所述的网络设备，其特征在于，所述传输控制模块还用于通过所述第二下行紧急控制信道向所述终端发送数据。

24.根据权利要求17到23任一权利要求所述的网络设备，其特征在于，所述多个子帧还包括第三子帧，所述第三子帧包括第三下行紧急信道、第三业务信道以及第三上行请求信道，所述第三下行紧急信道在所述第三业务信道以及所述第三上行请求信道之前，所述传输控制模块还用于通过所述第三下行紧急控制信道向所述终端发送第三控制信息，所述第三控制信息用于指示在所述第三子业务信道内，所述网络设备与所述终端间的信息传输方式，所述信息传输方式为上行传输或者下行传输；

所述数据传输模块还用于通过所述第三业务信道，使用所述信息传输方式与所述终端进行通信；

所述请求接收模块还用于通过所述第三上行请求信道，接收所述终端的上报信息，所述上报信息为第四业务的数据传输请求、第五业务的数据和预设的紧急指令的反馈消息中的至少一种，所述第四业务和所述第五业务为预设的紧急业务,所述第三上行请求信道仅用于传输所述上报信息。

25.一种终端，所述终端用于在时分双工TDD通信系统中通过多个子帧传输信息,所述时分双工TDD通信系统包括网络设备和终端，其特征在于，所述多个子帧包括第一子帧，所述第一子帧包括第一业务信道和第一上行请求信道，所述终端包括：

数据传输模块，用于通过所述第一业务信道与所述网络设备传输第一业务的数据；

请求上报模块，用于通过所述第一上行请求信道，向所述网络设备发送上报信息，所述上报信息为第二业务的数据传输请求、第三业务的数据和预设的紧急指令的反馈消息中的至少一种，所述第二业务和所述第三业务为预设的紧急业务。

26.根据权利要求25所述的终端，其特征在于，所述第一子帧为下行子帧，所述第一间隔与所述第一上行请求信道相邻所述第一子帧还包括第一间隔，并且所述第一间隔与所述第一上行请求信道相邻，在所述第一间隔内，所述网络设备与所述终端停止通信,在通过所述第一业务信道与所述网络设备传输第一业务的数据,所述数据传输模块用于通过所述第一业务信道接收所述网络设备发送的第一业务的数据。

27.根据权利要求25或26所述的终端，其特征在于，所述第一上行请求信道为所述第一子帧的倒数第二个正交分频复用OFDM符号(symbol)。

28.根据权利要求25到27任一权利要求所述的终端，其特征在于,所述第一上行请求信道仅用于传输所述上报信息。

29.根据权利要求25到28任一权利要求所述的终端，其特征在于，所述多个子帧还包括第二子帧，所述第二子帧在所述第一子帧之后，所述上报信息包括所述第二业务的数据传输请求，所述第二子帧包括第二下行紧急控制信道和第二业务信道，

所述终端还包括控制接收模块，所述控制接收模块用于接收来自所述网络设备的第二控制信息,所述第二控制信息用于指示在所述第二业务信道内，所述网络设备与所述终端之间的信息传输方式为上行传输；

所述数据传输模块还用于通过所述第二业务信道，向所述网络设备上报所述第二业务的数据。

30.根据权利要求29所述的终端，其特征在于，所述第二子帧还包括第二间隔，所述第二间隔位于所述第二业务信道与所述第二下行紧急控制信道之间，在所述第二间隔内，所述网络设备与所述终端停止通信。

31.根据权利要求29或30任一权利要求所述的终端，其特征在于，所述控制接收模块还用于通过所述第二下行紧急控制信道接收来自所述网络设备的数据。

32.根据权利要求25到31任一权利要求所述的终端，其特征在于，所述多个子帧还包括第三子帧，所述第三子帧包括第三下行紧急信道、第三业务信道以及第三上行请求信道，所述第三下行紧急信道在所述第三业务信道以及所述第三上行请求信道之前，

所述控制接收模块还用于通过所述第三下行紧急控制信道接收来自所述网络设备的第三控制信息，所述第三控制信息用于指示在所述第三业务信道内，所述网络设备与所述终端间的信息传输方式，所述信息传输方式为上行传输或者下行传输；

所述数据传输模块还用于通过所述第三业务信道，使用所述信息传输方式与所述终端进行通信；

所述请求上报模块还用于通过所述第三上行请求信道，向所述网络设备发送上报信息，所述上报信息为第四业务的数据传输请求、第五业务的数据和预设的紧急指令的反馈消息中的至少一种，所述第四业务和所述第五业务为预设的紧急业务,所述第三上行请求信道仅用于传输所述上报信息。

33.一种网络设备，所述网络设备用于在时分双工TDD通信系统中通过多个子帧传输信息,所述时分双工TDD通信系统包括所述网络设备与终端，其特征在于，所述多个子帧包括第一子帧，所述第一子帧包括第一业务信道和第一上行请求信道，所述网络设备包括处理器和收发器，所述处理器用于通过所述收发器，执行权利要求1到8所述的方法。

34.一种终端，所述终端用于在时分双工TDD通信系统中通过多个子帧传输信息,所述时分双工TDD通信系统包括网络设备与所述终端，其特征在于，所述多个子帧包括第一子帧，所述第一子帧包括第一业务信道和第一上行请求信道，所述终端包括处理器和收发器，所述处理器用于通过所述收发器，执行权利要求9到16所述的方法。