CN102123440A

CN102123440A - Control head confirming method and system

Info

Publication number: CN102123440A
Application number: CN2010100022248A
Authority: CN
Inventors: 张磊; 刘扬; 陈玉芹
Original assignee: ZTE Corp
Current assignee: ZTE Corp
Priority date: 2010-01-08
Filing date: 2010-01-08
Publication date: 2011-07-13
Anticipated expiration: 2030-01-08
Also published as: CN102123440B

Abstract

The invention discloses a control head confirming method and system. The control head confirming method comprises the following steps that: a sending end sends a control head to a receiving end; and the receiving end confirms that the control head from the sending end is received by sending the control head or a control message to the sending end. The control head confirming method and system enhance the transmission reliability when the control head is used as control signaling, thereby avoiding system failure caused by that the control head can not be correctly received.

Description

Control head confirmation method and system

Technical Field

The present invention relates to the field of communications, and in particular, to a method and a system for confirming a control header.

Background

In a wireless communication system, a base station is a basic unit constituting a cell, and performs communication and management functions between a mobile communication network and mobile communication subscribers. A base station communicates with a terminal via the uplink/downlink, where downlink refers to the direction from the base station to the terminal, and uplink refers to the direction from the terminal to the base station. A plurality of terminals may simultaneously transmit data to the base station through an uplink or simultaneously receive data from the base station through a downlink.

The base station and the terminal implement the functions of the Control plane through the interaction of Control messages (e.g., MAC Control messages). According to the technical development, in order to guarantee the transmission reliability of the control message, the communication system is designed to acknowledge the control message. For example, in a Worldwide Interoperability for Microwave Access (WiMAX) system design, Advanced Air interface Message Acknowledgement messages (AAI _ MSG-ACK) and MAC Control Message feedback extension headers (MAC Control Message ACK Extended headers, MAEH) are used to perform an Acknowledgement operation (ACK) on MAC Control messages. The confirmation operation specifically includes: if the terminal receives the MAC control message on the management connection and the polling field of the MAC Control Extension Header (MCEH) of the message is set to 1, the terminal must confirm to the base station that the message has been successfully received by transmitting AAI _ MSG-ACK or MAEH. Once the base station receives the AAI _ MSG-ACK/MAEH used for acknowledgement by the terminal, it considers that the terminal has successfully received the previously transmitted MAC control message. If the base station does not receive the acknowledgement from the terminal before the expiration of the time controlled by a certain timer, it is assumed that the terminal did not successfully receive the previously transmitted MAC control message, in which case the base station attempts to retransmit the MAC control message, and in particular, the base station has a maximum number of retransmission attempts limited.

In addition to Control messages, Control headers (Control headers) in the communication system may also be used to transmit Control information. For example, a control header of a WiMAX system design is: MAC headers (MAC headers), currently mainly include two types: a MAC Signaling Header (MAC Signaling Header) and an Extended Header (EH). The MAC signaling header may be sent by the base station/terminal alone or in combination with other MAC PDUs. The extension Header needs to be sent immediately after the Advanced Generic MAC Header (AGMH). An Extension Header (EH) field in the AGMH is used to indicate whether the AGMH carries an extension header.

In the prior art, the MAC signaling header and the extension header may be used to replace a separate MAC control message to implement the function of controlling signaling under certain conditions (for example, the conditions of bandwidth request and sleep mode application), so as to reduce the air interface overhead between the base station and the terminal due to the transceiving of the MAC control message, for example: the base station indicates a Sleep operation performed by the terminal using a Sleep Control Header (SCH) or a Sleep Control Extended Header (SCEH).

It should be further noted that, for the purpose of energy saving, a Sleep Mode (Sleep Mode) is provided in most mobile communication protocols. The Sleep mode provides Sleep cycles (SleepCycle) consisting of Listening windows (Listening Window) and Sleep windows (Sleep Window), and aims to reduce the energy consumption of the mobile terminal and the occupation of air interface resources of the serving base station. The dormant mode is a state that the terminal temporarily suspends the service of the service base station in a pre-negotiated specified period, namely that the base station does not unicast any form of downlink service to the terminal at the mobile terminal in the dormant window; however, within the Listening Window (Listening Window), the base station and the terminal may communicate in a normal manner. The base station may adjust the Sleep mode parameter, terminate the listening window, and extend the listening window by using the SCH/SCEH, which may effectively avoid an additional Air Interface overhead caused by interaction of Sleep control messages (e.g., Advanced Air Interface Sleep request Message (AAI _ SLP-REQ), Advanced Air Interface Sleep Response Message (AAI _ SLP-RSP)), and improve flexibility of Sleep mode operation.

According to the foregoing description, although the prior art uses the MAC signaling header and the extension header instead of the separate MAC control message to implement the function of the control signaling, the prior standard does not design a corresponding acknowledgement mechanism for the MAC signaling header and the extension header. It should be noted here that although the aforementioned AAI _ MSG-ACK message and MAEH are used for the acknowledgement operation of the general MAC control message, since they are designed to perform the acknowledgement operation on the fragment sequence number (e.g., ACK _ SN) of the received MAC control message, they can only be used for the acknowledgement of the MAC control message and cannot be used for the acknowledgement of the MAC signaling header and the extension header.

Obviously, if there is no mechanism similar to the MAC control message to ensure the transmission reliability of the MAC signaling header and the extension header, still taking the sleep mode as an example (see fig. 1), when the network has more downlink services to send, the base station may send SCH/scheh in the monitoring window to indicate the terminal to extend the monitoring window (for example, extend the length of several frames), and according to the current technology, the base station may carry SCH/scheh in the process of sending the downlink MAC PDU to indicate the terminal to perform the extension operation of the monitoring window. Under normal conditions, after the base station sends the SCH/scheh, the default terminal will extend the monitoring window according to the indication of the signaling, so even if the default monitoring window is finished, the base station will continue to send downlink traffic to the terminal. Of course, this does not present any problem if the terminal correctly receives and decodes the SCH/scheh indication of the base station. However, due to the lack of a corresponding acknowledgement mechanism to ensure transmission reliability during the SCH/scheh transmission, once the terminal fails to receive the SCH/scheh from the base station, it enters the sleep window after the end of the default listening window according to the normal operation. At this time, the base station is still transmitting downlink traffic, but the terminal is not in a monitoring state, the above problem caused by the failure of correct receiving of SCH/scheh will cause system abnormality, and in severe cases, the terminal must exit from the sleep mode to re-enter the network.

Disclosure of Invention

The technical problem to be solved by the present invention is to provide a method and a system for confirming a control header, so as to enhance the transmission reliability when the control header is used as a control signaling, thereby avoiding a system failure caused by the failure of the control header to receive correctly.

In order to solve the above technical problem, the present invention provides a method for confirming a control head, including:

the sending end sends a control head to the receiving end;

and the receiving end confirms that the control head from the sending end is received by sending the control head to the sending end.

Further, the method can also have the following characteristics:

the control head sent by the receiving end to the sending end is a special feedback control head.

Further, the method can also have the following characteristics:

and the special feedback control header carries an indication field for confirming whether the control header is used or not.

Further, the method can also have the following characteristics:

the indication field of whether to acknowledge the control header is 1 bit,

when the indication field is set to 0, the dedicated feedback control header is used for confirming a control message; when the indication field is set to 1, the dedicated feedback control header is indicated to be used for confirming the control header; or,

when the indication field is set to 1, the dedicated feedback control header is indicated to be used for confirming a control message; when the indication field is set to 0, it indicates that the dedicated feedback control header is used for confirming the control header.

Further, the method can also have the following characteristics: the dedicated feedback control header is a MAC control message feedback extension header (MAEH) with extended functions.

Further, the method can also have the following characteristics:

the type of the control head sent by the receiving end to the sending end is the same as that of the control head from the sending end.

Further, the method can also have the following characteristics:

the type of the control head is one of the following:

a sleep control header, a sleep control extension header, or a request header that does not carry a site identity specific service bandwidth.

Further, the method can also have the following characteristics:

the control header sent by the receiving end and/or the sending end carries an indication field, the indication field is 1 bit,

when the indication field is set to 0, the indication field indicates that the control header is a request signaling from the sending end and is used for indicating the receiving end to operate according to the requirement of the control header; when the indication field is set to 1, the indication field indicates that the control header is used for confirming the control header from the sending end; or,

when the indication field is set to 1, the indication field indicates that the control header is a request signaling from a sending end and is used for indicating a receiving end to operate according to the requirement of the control header; when the indication field is set to 0, it indicates that the control header is used for acknowledging the control header from the transmitting end.

Further, the method can also have the following characteristics:

the control head sent by the sending end to the receiving end carries an indication field, and the indication field is used for indicating whether the control head needs to be confirmed or not;

and the receiving end judges whether to send the control header for confirmation according to the received indication field in the control header, and sends the control header for confirmation to the sending end if the control header is sent for confirmation.

Further, the method can also have the following characteristics:

the control header sent by the receiving end to the sending end also carries a field for indicating the type of the control header from the sending end.

Further, the method can also have the following characteristics:

the control header sent by the receiving end to the sending end also carries a field for indicating one or more control headers from the sending end.

Further, the method can also have the following characteristics:

and the indication field carried in the control header sent by the receiving end to the sending end is a frame index and/or an execution identifier.

Further, the method can also have the following characteristics:

the method is applied to one or more of the following communication systems:

GSM，CDMA，EDGE，CDMA2000，TD-SCDMA，HSPA，WCDMA，EVDO，HSOPA，WiMAX，LTE，LTE-A。

the sending end sends a control head to the receiving end;

the receiving end confirms the reception of the control head from the transmitting end by sending a control message to the transmitting end.

Further, the method can also have the following characteristics:

the control message sent by the receiving end to the sending end is an advanced air interface message acknowledgement message (AAI _ MSG-ACK) after function expansion.

Further, the method can also have the following characteristics:

and the AAI _ MSG-ACK message after function expansion carries an indication field for confirming whether the control header is used or not.

Further, the method can also have the following characteristics:

the indication field of whether to acknowledge the control header is 1 bit,

when the indication field is set to 0, the AAI _ MSG-ACK message is used for confirming a control message; when the indication field is set to 1, the AAI _ MSG-ACK message is used for confirming a control header; or,

when the indication field is set to 1, the AAI _ MSG-ACK message is used for confirming a control message; when the indication field is set to 0, it indicates that the AAI _ MSG-ACK message is used for acknowledging a control header.

Further, the method can also have the following characteristics:

and the receiving end judges whether to send the control message for confirmation according to the received indication field in the control header, and if so, sends the control message for confirmation to the sending end.

Further, the method can also have the following characteristics:

the control message sent by the receiving end to the sending end also carries a field for indicating the type of the control header from the sending end.

Further, the method can also have the following characteristics:

the control message sent by the receiving end to the sending end also carries a field for indicating one or more control headers from the sending end.

Further, the method can also have the following characteristics:

and the indication field carried in the control message sent by the receiving end to the sending end is a frame index and/or an execution identifier.

In order to solve the above technical problem, the present invention provides a control header confirmation system, which includes a sending end and a receiving end,

the sending end is used for sending a control head to the receiving end;

and the receiving end is used for confirming the receiving of the control head from the sending end by sending the control head or the control message to the sending end after receiving the control head sent by the sending end.

The invention enhances the transmission reliability when the control head is used as the control signaling, thereby avoiding the system fault caused by the failure of the control head to receive correctly.

Drawings

FIG. 1 is a schematic diagram of an application according to the background of the invention;

FIGS. 2-13 are signaling interaction diagrams of embodiments of the present invention;

fig. 14 to 20 are operation principle diagrams of application examples of the present invention.

Detailed Description

The invention provides a method for confirming a received control head through the control head or a control message in order to solve the problem that a mechanism for confirming the control head is not available in the prior art.

Specifically, the invention proposes two methods to perform the confirmation operation on the control head:

the first method comprises the following steps:

and confirming the received control head by using the control head.

Specifically, the method comprises the following steps: the sending end sends a control head to the receiving end; and the receiving end confirms that the control head from the sending end is received by sending the control head to the sending end.

The sending end is a base station and the receiving end is a terminal, or the sending end is a terminal and the receiving end is a base station.

Specifically, three modes are specifically included:

mode 1:

the control Header used for acknowledging the received control Header may be a dedicated feedback control Header, for example, a MAC control Message acknowledgment extended Header (Message ackended Header, MAEH) with extended functionality.

In particular, the dedicated feedback control header carries an indication field for confirming whether the control header is used.

Preferably, the indication field indicating whether to acknowledge the control header may be 1 bit, and when the indication field is set to 0, it indicates that the dedicated feedback control header is used for acknowledging the control message; when the indication field is set to 1, the dedicated feedback control header is indicated to be used for confirming the control header; or, when the indication field is set to 1, it indicates that the dedicated feedback control header is used for acknowledging a control message; when the indication field is set to 0, it indicates that the dedicated feedback control header is used for confirming the control header.

Preferably, the control header sent by the sending end to the receiving end carries an indication field, where the indication field is used to indicate whether the control header needs to be confirmed; and the receiving end judges whether to send the control header for confirmation according to the received indication field in the control header, and sends the control header for confirmation to the sending end if the control header is sent for confirmation.

Preferably, the dedicated feedback control header sent by the receiving end to the sending end may further carry a field for indicating the type of the control header from the sending end (e.g., a signaling header, an extension header).

The dedicated feedback control header sent by the receiving end to the sending end may also carry a field for indicating the one or more control headers from the sending end, that is, indicating which control header or headers the dedicated feedback control header is used to specifically determine, where the field may be, specifically, an execution identifier (Transaction ID), a Frame Index (Frame Index), or the like.

Mode 2:

after receiving the control header from the sending end, the receiving end (base station/terminal) may respond to a control header of the same type (e.g., a sleep control header, a sleep control extension header, a request header without a site identifier specific service bandwidth) to confirm the received control header, that is, the type of the control header sent to the sending end by the receiving end is the same as the type of the control header from the sending end.

Further, the control header sent by the receiving end and/or the sending end carries an indication field, where the indication field may be 1 bit, and when the indication field is set to 0, it indicates that the control header is a request signaling from the sending end, and is used to indicate the receiving end to operate according to the requirement of the control header; when the indication field is set to 1, the indication field indicates that the control header is used for confirming the control header from the sending end; or, when the indication field is set to 1, the indication field indicates that the control header is a request signaling from the sending end, and is used for indicating the receiving end to operate according to the requirement of the control header; when the indication field is set to 0, it indicates that the control header is used for acknowledging the control header from the transmitting end.

Preferably, the control header sent by the sending end to the receiving end carries an indication field, where the indication field is used to indicate whether the control header needs to be confirmed; and the receiving end judges whether to send the control header for confirmation according to the received indication field in the MAC header, and if so, the receiving end sends the control header for confirmation to the sending end.

Preferably, the control header sent by the receiving end to the sending end may further carry a field for indicating the type of the control header from the sending end (e.g., a signaling header, an extension header).

The control header sent by the receiving end to the sending end may also carry a field for indicating the one or more control headers from the sending end, that is, indicating which control header or headers the control header or headers is used to specifically determine, where the field may be, specifically, an execution identifier (Transaction ID), a Frame Index (Frame Index), or the like.

Mode 3:

a new control header is defined, dedicated to acknowledge all control headers that may have been received.

In particular, the type of the newly defined control header may be a signaling header or an extension header.

Preferably, the newly defined control header may further carry a field for indicating the type (e.g., signaling header, extension header) of the control header from the transmitting end.

The newly defined control header may further carry a field for indicating the one or more control headers from the sending end, that is, for indicating which one or more control headers the newly defined control header is used to specifically identify, and in particular, the field may be an execution identifier (Transaction ID), a frame index (FrameIndex), or the like.

The second method comprises the following steps:

and confirming the received control head by using the control message.

Specifically, the method comprises the following steps: the sending end sends a control head to the receiving end; the receiving end confirms the reception of the control head from the transmitting end by sending a control message to the transmitting end.

Specifically, two modes are specifically included:

mode 1:

the above-mentioned control message used to acknowledge the received control header may be an AAI _ MSG-ACK message extended in function.

In particular, the function extended AAI _ MSG-ACK message carries an indication field for acknowledging the control header.

Preferably, the indication field indicating whether to acknowledge the control header may be 1 bit, and when the indication field is set to 0, it indicates that the AAI _ MSG-ACK message is used for acknowledging the control message; when the indication field is set to 1, the AAI _ MSG-ACK message is used for confirming a control header; or, when the indication field is set to 1, the AAI _ MSG-ACK message is used for acknowledging a control message; when the indication field is set to 0, it indicates that the AAI _ MSG-ACK message is used for acknowledging a control header.

Preferably, the control header sent by the sending end to the receiving end carries an indication field, where the indication field is used to indicate whether the control header needs to be confirmed; and the receiving end judges whether to send the control message for confirmation according to the received indication field in the MAC header, and if so, the receiving end sends the control message for confirmation to the sending end.

Preferably, the AAI _ MSG-ACK message may further carry a field for indicating the type of the control header from the transmitting end (e.g., a signaling header, an extension header).

The AAI _ MSG-ACK message may further carry a field for indicating the one or more control headers from the sending end, that is, a field for indicating which control header or headers the AAI _ MSG-ACK message is used to specifically acknowledge, and in particular, the field may be an execution identifier (Transaction ID), a Frame Index (Frame Index), or the like.

Mode 2:

a new control message is defined, dedicated to acknowledge all control headers that may have been received.

Preferably, the control header sent by the sending end to the receiving end carries an indication field, where the indication field is used to indicate whether the control header needs to be confirmed; and the receiving end judges whether to send the control message for confirmation according to the received indication field in the control header, and if so, sends the control message for confirmation to the sending end.

Preferably, the newly defined control message may also carry a field for indicating the type (e.g., signaling header, extension header) of the control header from the transmitting end.

The newly defined control message may also carry a field for indicating the one or more control headers from the sending end, that is, a field for indicating which control header or headers the newly defined control message is used to specifically identify, for example, the field may be an execution identifier (Transaction ID), a frame index (FrameIndex), or the like.

The present invention is applicable to, but not limited to, the following communication systems: GSM, CDMA, EDGE, CDMA2000, TD-SCDMA, HSPA, WCDMA, EVDO, HSOPA, WiMAX, LTE, LTE-A.

The invention is described in detail below with reference to the figures and the specific embodiments.

Example one

As shown in fig. 2, the terminal receives the MAC signaling header from the base station and then sends MAEH to the base station to confirm that the terminal has successfully received the indication from the base station. Wherein the related field of MAEH indicates that it is an acknowledgement of the MAC header. And the base station receives the MAEH and confirms that the terminal has received the MAC signaling header transmitted before.

Example two

As shown in fig. 3, the base station sends a MAC signaling header to the terminal, and the terminal is required to perform related operations according to the indication. The MAC signaling header sent by the base station carries an indication that the terminal needs to confirm the operation.

The terminal receives the MAC signaling header from the base station and then sends MAEH to the base station to confirm that the terminal has successfully received the indication from the base station. Wherein the related field of MAEH indicates that it is an acknowledgement of the MAC header. And the base station receives the MAEH and confirms that the terminal has received the MAC signaling header transmitted before.

EXAMPLE III

As shown in fig. 4, the terminal receives the MAC signaling header from the base station (the PDU in which the signaling header also includes the extension header), and then sends MAEH to the base station to confirm that the terminal has successfully received the indication from the base station. Wherein the related field of MAEH indicates that it is an acknowledgement of the MAC header. At the same time, some fields of the MAEH also indicate that it is acknowledging the signaling header. And the base station receives the MAEH and confirms that the terminal has received the MAC signaling header transmitted before.

Example four

As shown in fig. 5, the terminal receives three MAC extension headers (e.g., three same SCEH, but instructing the terminal to perform different operations) from the base station, wherein fields carried by the first and third MAC extension headers indicate that the terminal needs to acknowledge. The terminal then transmits a MAEH to the base station to confirm that the terminal has successfully received the indication from the base station. Wherein the associated field of the MAEH indicates that it is an acknowledgement that the first and third extension headers have been received. The base station receives the MAEH and confirms that the terminal has received the previously transmitted first and third MAC extension headers.

EXAMPLE five

As shown in fig. 6, the terminal receives two MAC extension headers (e.g., two different extension headers, one SCEH, one bandwidth request extension header) from the base station. The terminal then first sends a MAEH to the base station to confirm that the terminal has successfully received the indication from the base station. The relevant field of MAEH indicates that it is an acknowledgement of the first extension header that has been received.

Next, the terminal sends another MAEH to the base station, and unlike the previously sent MAEH, the related field of the MAEH indicates that it is acknowledging the received second extension header.

And the base station receives the MAEH and confirms that the terminal has received the two MAC extension headers transmitted before.

EXAMPLE six

As shown in fig. 7, the base station sends a MAC signaling header to the terminal, and the terminal is required to perform related operations according to the indication.

The terminal receives the MAC signaling header from the base station and then sends a MAC signaling header of the same type to the base station to confirm that the terminal has successfully received the indication from the base station. The base station receives the MAC signaling header and confirms that the terminal has received the previously sent MAC signaling header.

EXAMPLE seven

As shown in fig. 8, the terminal receives three MAC extension headers (e.g., three same SCEH, but instructs the terminal to perform different operations) from the base station, and requests the terminal to perform related operations according to the instructions. The first and third MAC extension headers sent by the base station carry an indication that the terminal is required to perform an acknowledgement operation on the MAC extension header.

The terminal receives the MAC extension header from the base station and then sends a MAC extension header of the same type to the base station to confirm that the terminal has successfully received the indication from the base station. The relevant field of the MAC extension header also indicates that the MAC extension header acknowledges that the first and third extension headers have been received. The base station receives the MAC extension header and confirms that the terminal has received the first and third MAC extension headers transmitted previously.

Example eight

As shown in fig. 9, the terminal receives the MAC signaling header from the base station and then sends an AAI _ MSG-ACK message to the base station to confirm that the terminal has successfully received the indication from the base station. Wherein the relevant field of the AAI _ MSG-ACK message indicates that it is an acknowledgement of the MAC header. The base station receives the AAI _ MSG-ACK message and confirms that the terminal has received the MAC signaling header sent before.

Example nine

As shown in fig. 10, the base station sends a MAC signaling header to the terminal, and the terminal is required to perform related operations according to the indication. The MAC signaling header sent by the base station carries an indication that the terminal needs to confirm the operation.

The terminal receives the MAC signaling header from the base station and then sends an AAI _ MSG-ACK message to the base station to confirm that the terminal has successfully received the indication from the base station. Wherein the relevant field of the AAI _ MSG-ACK message indicates that it is an acknowledgement of the MAC header. The base station receives the AAI _ MSG-ACK message and confirms that the terminal has received the MAC signaling header sent before.

Example ten

As shown in fig. 11, the terminal receives the MAC signaling header from the base station and then sends an AAI _ MSG-ACK message to the base station to confirm that the terminal has successfully received the indication from the base station. Wherein the relevant field of the AAI _ MSG-ACK message indicates that it is an acknowledgement of the MAC header. At the same time, some fields of the AAI _ MSG-ACK message also indicate that it is acknowledging the signaling header. The base station receives the AAI _ MSG-ACK message and confirms that the terminal has received the MAC signaling header sent before.

EXAMPLE eleven

As shown in fig. 12, the terminal receives three MAC extension headers from the base station (e.g., three identical SCEHs but instructing the terminal to operate differently), and then sends an AAI _ MSG-ACK message to the base station to confirm that the terminal has successfully received the indication from the base station. Wherein the relevant field of the AAI _ MSG-ACK message indicates that it is an acknowledgement that the first and third extension headers have been received. The base station receives the AAI _ MSG-ACK message, confirming that the terminal has received the previously transmitted first and third MAC extension headers.

Example twelve

As shown in fig. 13, the terminal receives two MAC extension headers (e.g., two different extension headers, one SCEH, one bandwidth request extension header) from the base station. Subsequently, the terminal first sends an AAI _ MSG-ACK message to the base station to acknowledge that the terminal has successfully received the indication from the base station. The relevant field of the AAI _ MSG-ACK message indicates that it acknowledges the first extension header that has been received.

The terminal then sends a further AAI _ MSG-ACK message to the base station, which, unlike the previously sent AAI _ MSG-ACK message, has an associated field indicating that it acknowledges the second extension header that has been received.

The base station receives the AAI _ MSG-ACK message and confirms that the terminal has received the two MAC extension headers transmitted before.

The MAC header confirmation system of the embodiment of the invention comprises a sending end and a receiving end,

the sending end is used for sending an MAC (media access control) header to the receiving end;

the receiving end is used for confirming that the MAC head from the sending end is received by sending the MAC head or the MAC control message to the sending end after receiving the MAC head sent by the sending end.

Application example of a specific scenario:

application example 1

As shown in fig. 14, the terminal in the normal operation mode enters the sleep mode through message interaction with the base station. And the base station sends downlink service to the terminal in a monitoring window of a sleep period negotiated with the terminal. In a monitoring window, a base station has a large amount of downlink services to be sent to a terminal, but according to the previous dormancy configuration, the length of the default monitoring window at the moment of the terminal cannot complete the reception of all currently generated downlink services. Therefore, the base station determines to instruct the terminal to extend the listening window, and then the base station instructs the terminal to extend the listening window by sending a Sleep Control Header (SCH)/Sleep Control Extended Header (scheh) carrying a relevant field in a default listening window. The relevant indication field of SCH/scheh may indicate that the SCH/scheh is a request signaling from the base station (specific settings may refer to the format of table 1).

The terminal receives the SCH/SCEH from the base station in the default monitoring window, and the terminal knows that the base station instructs the base station to perform the expansion operation of the monitoring window through decoding. The terminal then sends MAEH to the base station and sets the MAEH subtype field therein to acknowledge the MAC header (the specific settings may refer to the format of table 2). The base station receives the MAEH from the terminal, confirms that the terminal has expanded the monitoring window according to the requirement, and then continuously sends the downlink service to the terminal in the expanded monitoring window.

TABLE 1 reference Format for SCH/SCEH

Field(s)	Length (bit)	Note
			SCH/SCEH(){
Type (B)	4	SCH/SCEH types

SCH/SCEH subtype	1	0: SCH/SCEH is used as a request indication 1: SCH/SCEH use as an acknowledgement indication
			If (SCH/scheh subtype ═ 1) retaining eye
Acknowledgement indication	1	0: no terminal is required to confirm 1: requiring the terminal to acknowledge
			}
Intense (SCH/scheh subtype ═ 0) arch support
			SCH/SCEH operation subtype	2	00: listening window control 01: resume sleep cycle indication 10: multicarrier listening window control 11: modifying sleep cycle configuration
…
			…
}
			}

Table 2 reference format for MAEH

Field(s)	Length (bit)	Note
			MAEH(){
Type (B)	4	MAEH type

MAEH subtype	1	0 is used as an acknowledgement for the MAC control message; 1-is used as an acknowledgement to the MAC header;
			if (MAEH subtype ═ 0) retaining curl
ACK_SN	8	SN retrieved from MAC PDU with polling field of MCEH set to 1;
			}
else{
			MAC header type	4	Indicating acknowledgement of a certain type of header
Frame index	4	4LSB
			}
}

Application example two

As shown in fig. 15, the terminal in the normal operation mode enters the sleep mode through message interaction with the base station. And the base station sends downlink service to the terminal in a monitoring window of a sleep period negotiated with the terminal. In a monitoring window, a base station has a large amount of downlink services to be sent to a terminal, but according to the previous dormancy configuration, the length of the default monitoring window at the moment of the terminal cannot complete the reception of all currently generated downlink services. Therefore, the base station determines to instruct the terminal to extend the listening window, and then the base station instructs the terminal to extend the listening window by sending a Sleep Control Header (SCH)/Sleep Control Extended Header (scheh) carrying a relevant field in a default listening window. The relevant indication field of SCH/scheh may indicate that the SCH/scheh is a request signaling from the base station (specific settings may refer to the format of table 1).

The terminal receives the SCH/SCEH from the base station in the default monitoring window, and the terminal knows that the base station instructs the base station to perform the expansion operation of the monitoring window through decoding. The terminal then sends a unicast AAI _ MSG-ACK message to the base station, with the message type field set to the MAC header acknowledgement (the specific parameter settings of the message may refer to the format of table 3) to indicate that the AAI _ MSG-ACK message is now used for MAC header acknowledgement. The base station receives the AAI _ MSG-ACK message from the terminal, confirms that the terminal expands the monitoring window according to the requirement, and then continuously sends downlink service to the terminal in the expanded monitoring window.

TABLE 3AAI _ MSG-ACK reference Format

Name (R)	Length (bit)	Application method
			Message type	1	0 is used as an acknowledgement for the MAC control message; 1-is used as an acknowledgement to the MAC header;
ACK_SN	8	SN retrieved from MAC PDU with polling field of MCEH set to 1; this entry is only in the case where the message type is set to 0
					Is present under the conditions;
channel ID	1	A Channel identifier (Channel ID) of the received MAC control message; this entry exists only if the message type is set to 0;

application example three

As shown in fig. 16, the terminal in the normal operation mode enters the sleep mode through message interaction with the base station. And the base station sends downlink service to the terminal in a monitoring window of a sleep period negotiated with the terminal. In a monitoring window, a base station has a large amount of downlink services to be sent to a terminal, but according to the previous dormancy configuration, the length of the default monitoring window at the moment of the terminal cannot complete the reception of all currently generated downlink services. Therefore, the base station determines to instruct the terminal to extend the listening window, and then the base station instructs the terminal to extend the listening window by sending a Sleep Control Header (SCH)/Sleep Control Extended Header (scheh) carrying a relevant field in a default listening window. The relevant indication field of SCH/scheh may indicate that the SCH/scheh is a request signaling from the base station (specific settings may refer to the format of table 1).

The terminal receives the SCH/SCEH from the base station in the default monitoring window, and the terminal knows that the base station instructs the base station to perform the expansion operation of the monitoring window through decoding. The terminal then transmits SCH/scheh to the base station and sets SCH/scheh subtype field therein to 1 (specific settings may refer to the format of table 1). The base station receives the AAI _ MSG-ACK message from the terminal, confirms that the terminal expands the monitoring window according to the requirement, and then continuously sends downlink service to the terminal in the expanded monitoring window.

Application example four

As shown in fig. 17, the terminal in the normal operation mode enters the sleep mode through message interaction with the base station. And the base station sends downlink service to the terminal in a monitoring window of a sleep period negotiated with the terminal. In a monitoring window, a base station has a large amount of downlink services to be sent to a terminal, but according to the previous dormancy configuration, the length of the default monitoring window at the moment of the terminal cannot complete the reception of all currently generated downlink services. Therefore, the base station determines to instruct the terminal to extend the listening window, and then the base station instructs the terminal to extend the listening window by sending a Sleep Control Header (SCH)/Sleep Control Extended Header (scheh) carrying a relevant field in a default listening window. The relevant indication field of SCH/scheh may indicate that the SCH/scheh is a request signaling from the base station (specific settings may set SCH/scheh subtype to 0 with reference to the format of table 1).

The terminal receives the SCH/SCEH from the base station in the default monitoring window, and knows that the base station is indicating the base station to perform the expansion operation of the monitoring window through decoding. The terminal then sends SCH/SCEH/MAEH/AAI _ MSG-ACK to the base station, confirming that the indication from the base station has been successfully received. Before the extended monitoring window is finished, the base station finishes sending all downlink services in advance, and at the moment, the base station sends SCH/SCEH to indicate the terminal to finish the monitoring window in advance and enter a sleep window for power saving. The terminal receives the SCH/scheh from the base station in the extended listening window, and knows that the base station is instructing it to terminate the listening window by decoding. And then, the terminal sends SCH/SCEH/MAEH/AAI _ MSG-ACK to the base station, confirms that the indication of the base station is successfully received, and then ends the monitoring window to enter a sleep window.

The base station receives the information from the terminal and confirms that the terminal enters the sleep window according to the requirement.

Application example five

As shown in fig. 18, the terminal in the normal operation mode enters the sleep mode through message interaction with the base station. And the base station sends downlink service to the terminal in a monitoring window of a sleep period negotiated with the terminal. Particularly, in the case that the base station does not instruct the terminal to extend the listening window, the terminal enters the sleep window after the default listening window is finished.

And in the dormant window, the terminal generates uplink service to be sent, and at the moment, the terminal interrupts the operation of the dormant window to send an uplink bandwidth request. The base station receives a bandwidth request from the terminal, and sends a Sleep Control Header (SCH for short) and a Sleep Control extended Header (SCEH for short) carrying corresponding fields to indicate that the terminal returns to a Sleep window, and resumes a normal Sleep operation. The terminal receives the SCH/scheh from the base station during the listening window generated by the temporary interruption, and knows that the base station is instructing it to return to the sleep window by decoding. The terminal sends SCH/SCEH/MAEH/AAI _ MSG-ACK to the base station, confirms that the indication of the base station is successfully received, and then ends the monitoring window to enter the sleep window.

The base station receives the information from the terminal, confirms that the terminal enters the sleep window according to the requirement, and recovers the normal sleep operation. Then, the base station will send the information carrying the allocated bandwidth resource to the terminal in the next listening window of the terminal.

Application example six

As shown in fig. 19, the terminal in the normal operation mode enters the sleep mode through message interaction with the base station. And the base station sends downlink service to the terminal in a monitoring window of a sleep period negotiated with the terminal. In a monitoring window, a base station has a large amount of downlink services to be sent to a terminal, but according to the previous dormancy configuration, the length of the default monitoring window at the moment of the terminal cannot complete the reception of all currently generated downlink services. Therefore, the base station determines to instruct the terminal to extend the listening window, and then the base station instructs the terminal to extend the listening window by sending a Sleep Control Header (SCH)/Sleep Control Extended Header (scheh) carrying a relevant field in a default listening window. The relevant indication field of SCH/scheh may indicate that the SCH/scheh is a request signaling from the base station (specific settings may refer to the format of table 1).

The terminal receives the SCH/SCEH from the base station in the default monitoring window, and knows that the base station is indicating the base station to perform the expansion operation of the monitoring window through decoding. The terminal may then transmit a SCH/SCEH/MAEH/AAI _ MSG-ACK to the base station acknowledging the indication that the base station has been successfully received. Before the extended monitoring window is finished, the base station completes the sending of all downlink services, and at this time, the base station sends SCH/scheh to indicate the terminal to apply a new sleep mode configuration (for example, the terminal is instructed to switch the sleep configuration by carrying SCID) due to the need of a new service. The terminal receives the SCH/scheh from the base station in the extended listening window, and knows that the base station is instructing it to adjust the sleep mode configuration. The terminal sends SCH/SCEH/MAEH/AAI _ MSG-ACK to the base station, confirms that the indication of the base station has been successfully received, and then applies the adjusted sleep mode configuration at the time specified by the base station according to the indication of the base station.

The base station receives the information from the terminal and confirms that the terminal has adjusted the sleep mode configuration as required.

Application example seven (specific service Bandwidth request header without site identification)

As shown in fig. 20, the terminal in the normal operation mode enters the sleep mode through message interaction with the base station. And the base station sends downlink service to the terminal in a monitoring window of a sleep period negotiated with the terminal. In a monitoring window, a base station has a large amount of downlink services to be sent to a terminal, but according to the previous dormancy configuration, the length of the default monitoring window at the moment of the terminal cannot complete the reception of all currently generated downlink services. Therefore, the base station determines to instruct the terminal to extend the listening window, and then the base station instructs the terminal to extend the listening window by sending a Sleep Control Header (SCH)/Sleep Control Extended Header (scheh) carrying a relevant field in a default listening window. The relevant indication field of SCH/scheh may indicate that the SCH/scheh is a request signaling from the base station (specific settings may refer to the format of table 1).

The terminal receives the SCH/SCEH from the base station in the default monitoring window, and knows that the base station is indicating the base station to perform the expansion operation of the monitoring window through decoding. The terminal may then transmit a SCH/SCEH/MAEH/AAI _ MSG-ACK to the base station acknowledging the indication that the base station has been successfully received. Before the extended listening window is finished, the base station completes the sending of all downlink services, and at this time, because of the need of a new Service (for example, the QoS of the Service changes), the base station sends a Service Specific BR with a Specific Service bandwidth Header (Service Specific BR with a STID Header) that does not carry a site identifier to instruct the terminal to apply a new sleep mode configuration (for example, to instruct the terminal to switch the sleep configuration by carrying a new SCID). The terminal receives a request header which does not carry a site identification specific service bandwidth from the base station in an extended monitoring window, and learns that the base station indicates the base station to adjust the sleep mode configuration through a received SCID change indication bit (SCID change indicator). The terminal sends MAEH/AAI _ MSG-ACK/Service Specific BRwithout STID Header to the base station, confirms that the indication of the base station is successfully received, and then applies the adjusted sleep mode configuration at the time specified by the base station according to the indication of the base station.

Application example eight (Bandwidth request header)

The terminal in the normal working process generates uplink service and needs to send the uplink service to the base station. The terminal sends a bandwidth request to the base station using a bandwidth request signaling Header/extension Header (e.g., BR with STID Header/BR with out STID Header/PBREH). The base station receives the request of the terminal, immediately responds to the bandwidth request signaling header/bandwidth request extended header/MAEH/AAI _ MSG-ACK to the terminal, and is used for confirming that the bandwidth request information from the terminal is successfully received. Then, the base station allocates uplink bandwidth resources to the terminal according to the request of the terminal.

The present invention may be embodied in other specific forms without departing from the spirit or essential attributes thereof, and it should be understood that various changes and modifications can be effected therein by one skilled in the art without departing from the spirit and scope of the invention as defined in the appended claims.

Claims

1. A method of validation of a control head, comprising:

the sending end sends a control head to the receiving end;

2. The method of claim 1,

3. The method of claim 2,

4. The method of claim 3,

the indication field of whether to acknowledge the control header is 1 bit,

5. The method of claim 2,

the dedicated feedback control header is a MAC control message feedback extension header (MAEH) with extended functions.

6. The method of claim 1,

7. The method of claim 6,

the type of the control head is one of the following:

8. The method of claim 6,

9. The method according to any one of claims 1 to 8,

10. The method according to any one of claims 1 to 8,

11. The method according to any one of claims 1 to 8,

12. The method of claim 11,

13. The method according to any one of claims 1 to 8,

the method is applied to one or more of the following communication systems:

14. a method of validation of a control head, comprising:

the sending end sends a control head to the receiving end;

15. The method of claim 14,

16. The method of claim 14,

17. The method of claim 16,

the indication field of whether to acknowledge the control header is 1 bit,

18. The method according to any one of claims 14 to 17,

19. The method according to any one of claims 14 to 17,

20. The method according to any one of claims 14 to 17,

21. The method of claim 20,

22. A confirmation system of a control head comprises a sending end and a receiving end, and is characterized in that,

the sending end is used for sending a control head to the receiving end;