CN111294163B

CN111294163B - DigRF retransmission failure processing method and device

Info

Publication number: CN111294163B
Application number: CN202010394797.3A
Authority: CN
Inventors: 檀甲甲; 朱学庆; 陈松
Original assignee: Aojie Technology Shanghai Co ltd
Current assignee: ASR Microelectronics Co Ltd
Priority date: 2020-05-12
Filing date: 2020-05-12
Publication date: 2020-08-11
Anticipated expiration: 2040-05-12
Also published as: CN111294163A

Abstract

The application discloses a DigRF retransmission failure processing method, which comprises the following steps. Step S10: the receiving party finds that the frame transmitted by the DigRF protocol has the condition of retransmission failure, and the receiving party sends a NACK frame of the retransmitted frame to the sending party; the frame in which retransmission fails is called a lost frame. Step S20: and the transmitting party receives the NACK frame of the retransmission frame and informs the receiving party of the ID and/or retransmission sequence of the data logical channel in the lost frame. Step S30: the receiving party receives the ID and/or retransmission sequence of the data logic channel in the lost frame, knows the length of the lost frame and the attribution of the lost frame data, and fills the locally generated compensation data in the position of the lost frame. According to the method and the device, after retransmission failure occurs in the DigRF interface, the correctness of the data time sequence after the frame is lost can be ensured, performance loss or call drop and the like caused by a traditional method are avoided, and the overall robustness of the system is improved.

Description

DigRF retransmission failure processing method and device

Technical Field

The present application relates to a method for transmitting between chips in a UE (user equipment) for mobile communication.

Background

In a mobile communication system, the radio frequency circuit and the baseband circuit in the UE are usually designed and manufactured as two chips, RFIC and BBIC. An analog interface is adopted between an early mobile phone baseband chip and a radio frequency chip, and with the enhancement of mobile phone integration level and chip function, a digital baseband interface is adopted in modern mobile phones. If a parallel digital interface is adopted, a large amount of pin and wiring space is occupied, and meanwhile, if the signal definitions of various chip manufacturers are different, a plurality of compatibility problems are brought to mobile phone manufacturers, so that a standard is needed to unify the digital interface between the baseband chip and the radio frequency chip on the mobile phone. In the current mobile phone, a DigRF (Digital radio frequency) interface is usually used to connect the baseband chip and the RF chip. The DigRF interface realizes the digitization and standardization of the interface between the baseband chip and the radio frequency chip inside the mobile phone, and provides more flexible choices for mobile phone designers while providing high-speed data transmission capability. This means that the RFIC chip and the BBIC chip can be designed by different manufacturers, and they work cooperatively through DigRF interface compatibility.

The DigRF organization joined the MIPI (Mobile Industry Processor Interface) alliance in 2007 and became a working group, which formally released the DigRF V4 standard in 2010. Referring to fig. 1, this is the connection between RFIC and BBIC chips defined by the most basic DigRF V4 standard. In the 3G and 4G era, the DigRF V4 protocol becomes the mainstream DigRF interface protocol. With the development of technology, it is mainstream for one manufacturer to design RFIC and BBIC at the same time, so that customization of DigRF protocol is possible. With the advent of the 5G era, manufacturers began to modify and customize DigRF interface protocols according to their needs, but the DigRF interface protocols are generally modified based on the DigRF V4 standard.

There are two frame structures in the DigRF V4 protocol, the first being the normal frame (normal frame) structure and the second being the frame structure employing the Nesting (NEST) mechanism. Referring to fig. 2, two consecutive normal frame structures are shown. Each normal Frame sequentially includes an SOF (Start Of Frame) flag, a Header, a Payload (i.e., transmitted data), a CRC (Cyclic Redundancy Check), and an EOF (End Of Frame) flag from front to back.

There are also some frames with higher timeliness in the DigRF V4 protocol, such as NACK (negative acknowledgement) frames or TAS (Timing access burst) frames, that need to be sent first. The digrv 4 protocol designs a nesting mechanism to send high priority frames first in time. Referring to fig. 3, the nesting mechanism embeds a high priority Frame into a non-high priority Frame, where the high priority Frame is called a Nested Frame (Nested Frame), and the embedded non-high priority Frame is called an encapsulation Frame (Encapsulating Frame). One or more nested frames may be embedded within a packaged frame.

In the normal frame structure defined by the DigRF V4 protocol, the header is divided into two types: type one (Type 1) and Type two (Type 2). Referring to fig. 4, this is a header of type one, and has a length of 8 bits (bit), and sequentially from front to back, an RTI (Retransmission Indicator) field, a CRI (Cyclic Running Index) field, an XLC _ ID field, and an LCI (logical Channel Indicator) field. The RTI field has a length of 1 bit and indicates whether it is a retransmission frame. The CRI field is 3 bits in length, taking a cycle of decimal numbers 0 to 7 to indicate the frame number. The length of the XLC _ ID field is 3 bits, and X denotes D or C, which is used to indicate the ID of the current Data Logical Channel (DLC) or Control Logical Channel (CLC). The LCI field has a length of 1 bit and indicates whether it is a data logical channel or a control logical channel. It should be noted that the CRI field of the nested frame is accumulated on the basis of the CRI field of the encapsulated frame.

The type two header is followed by a Byte (Byte) of type one header, and has a total length of 2 bytes. Referring to fig. 5, this is the case one of type two headers. For control logical channels, type two headers are only used if the CLC _ ID field is equal to the decimal number 5 (THLCLC) or 7 (TSLCC), and the newly added CLC _ LEN field of one byte is used to indicate the frame length.

Please refer to fig. 6, which shows the case two of the type two header. For data logical channels, type two headers are only used if the DLC _ ID field equals decimal 7, where the number of data logical channels can be extended by a four bit length SDLC _ ID field in the second byte, i.e. the ID of the real data logical channel equals the content of the DLC _ ID field at that time (i.e. decimal 7) plus the content of the SDLC _ ID field.

An ARQ (Automatic Repeat Request) mechanism is also specified in the DigRF V4 protocol. Once the receiver finds that a certain frame is wrong, a NACK frame is sent to the sender to inform the sender of retransmission. The criteria for determining that a frame has an error include the occurrence of a 8B10B decoding error, a Marker (Marker) error that missed or misdetected the SOF/EOF/EOT, a CRC check failure, etc. Once the transmitting side receives the NACK frame, it retransmits according to the information of the CRI field included in the NACK frame. But only one retransmission is supported in the DigRF V4 protocol. If retransmission is wrong again, although the receiving side feeds back a NACK frame to the transmitting side, the transmitting side does not retransmit again, but notifies the receiving side of retransmission failure by transmitting two consecutive empty frames (dummy frames). The null frame does not contain any information. The receiver cannot do any remedy for the lost frame at this point. But retransmission failure is a serious disaster for the receiving party. For example, for downlink reception, the RFIC chip transmits data to the BBIC chip through a data logical channel, and if retransmission failure occurs, that is, one frame of data is lost, data subsequently received by the BBIC chip is completely misplaced in Timing (Timing), which may result in complete failure of subsequent reception, thereby possibly causing a call drop or significant performance loss.

In the prior art, only retransmission failure of the DigRF interface can be recognized, and no compensation or correction mechanism is provided, so that once retransmission failure occurs, only a receiver, a sender and even a system can be restarted. For the control logical channel, because the amount of data on the channel is low, retransmission failures occur relatively infrequently, for example, only once in a few years on average, and so such a process is acceptable. But for data logical channels, the amount of data transmitted is large. In conventional 3G, 4G, etc. mobile communication systems, since the BER (bit error rate) of DigRF interface transmission can be controlled at a low level and the data transmission rate is relatively low, the probability of occurrence of retransmission failure is relatively low, for example, it will occur only once in several months on average, and thus it is relatively acceptable. However, with the development of 5G and other technologies, the data transmission rate is greatly improved, but the BER of DigRF interface transmission generally cannot be continuously reduced, so the occurrence probability of retransmission failure becomes significantly large, for example, the retransmission failure occurs once every few weeks or even days on average, and thus, the overall performance of the system and the user experience are significantly affected.

Disclosure of Invention

The technical problem to be solved by the application is to improve a handling mechanism of retransmission failure in a DigRF V4 protocol, and the time sequence of subsequent received data cannot be influenced when the retransmission fails, so that the overall performance of the system and the user experience are improved.

In order to solve the above technical problem, the present application provides a method for processing a DigRF retransmission failure, including the following steps. Step S10: the method comprises the following steps that a receiver finds that a retransmission failure occurs in a frame transmitted through a DigRF protocol, wherein the retransmission failure refers to the situation that the receiver finds that an error occurs in a certain frame received and requires a sender to retransmit, and then the receiver finds that the received retransmitted frame is still in error; a receiving side sends a NACK frame of a retransmission frame to a sending side; the frame in which retransmission fails is called a lost frame. Step S20: and the transmitting party receives the NACK frame of the retransmission frame and informs the receiving party of the ID and/or retransmission sequence of the data logical channel in the lost frame. Step S30: the receiving party receives the ID and/or retransmission sequence of the data logic channel in the lost frame, knows the length of the lost frame and the attribution of the lost frame data, and fills the locally generated compensation data in the position of the lost frame. The core idea of the application is that: for the case of retransmission failure, the sender may notify the receiver of information (e.g., information such as ID of data logical channel, retransmission order, etc.), so that the receiver may determine the length and attribution (which cell, antenna, and IQ) of the lost data by using the information, and thus may fill in the locally generated corresponding amount of compensation data (e.g., all-zero data or random number, etc.) at the location where the corresponding data is lost, thereby ensuring that no timing error occurs in the subsequent received data, and improving the robustness of the overall system.

Further, the sender and the receiver are an RFIC chip and a BBIC chip in the user equipment, respectively; or vice versa. This is an illustration of the application scenario of the DigRF protocol.

In step S10, the frame transmitted by the DigRF protocol refers to a frame transmitted by a data logical channel of the DigRF protocol. This indicates that the preferred application scope of the present application is the retransmission failure situation of the data logical channel.

Further, in the step S10, the case where the retransmission fails refers to the following case; firstly, a receiver finds that a certain received frame has errors, and the receiver sends a NACK frame to a sender to inform the sender to retransmit the frame; then, the sender receives the NACK frame and retransmits the error frame to the receiver according to the CRI field information contained in the NACK frame; then, the receiver finds that the received retransmission frame is still wrong, that is, the retransmission fails. This is a detailed description and illustration of the failure to retransmit.

Further, in step S20, when there is only one lost frame, the transmitting side informs only the receiving side of the ID of the data logical channel in the lost frame. When the number of the lost frames is more than one, the transmitting side informs the receiving side which lost frame is currently described, i.e. the retransmission order, and the ID of the data logical channel in the currently described lost frame. This is illustrative of the different coping strategies of step S20 in different situations.

Further, in step S20, the sender uses two consecutive empty frames to inform the receiver of the ID and/or retransmission order of the data logical channel in the lost frame; and recording the ID and/or retransmission sequence of the data logical channel of the lost frame in the load of any one or two empty frames. This is a preferred implementation and satisfies compatibility with existing DigRF protocols.

Further, in said step S20, if the header of the lost frame is the header of type one, only the content of the DLC _ ID field of the lost frame is recorded in the payload of the empty frame; if the header of the lost frame is a type two header, the contents of the DLC _ ID field and SDLC _ ID field of the lost frame are recorded in the payload of the empty frame. Since the ID of the data logical channel adopts different recording methods in different types of headers, a corresponding notification method is required.

Further, in the step S30, the attribution of the lost frame data includes which cell the lost frame belongs to, an antenna, and IQ information. This is an explanation of the meaning of attribution of lost frame data.

Further, in step S30, the compensation data is any one or more of a fixed constant, a locally generated random number, or residual data in an original memory. This is illustrative of some common ways of generating compensation data.

The application also provides a DigRF retransmission failure processing device, which comprises a detection unit, an informing unit and a compensation unit. The detection unit is used for sending NACK frame of retransmission frame to the sender by the receiving side when the receiving side finds that the retransmission of the frame transmitted by the DigRF protocol fails; the retransmission failure means that the receiver finds that an error occurs in a received frame and requires the transmitter to retransmit, and then the receiver finds that the received retransmitted frame is still in error; the frame in which retransmission fails is called a lost frame. The informing unit is used for informing the ID and/or the retransmission sequence of the data logical channel in the lost frame to the receiving party by the sending party after the sending party receives the NACK frame of the retransmission frame. The compensation unit is used for acquiring the length of the lost frame and the attribution of the lost frame data after the receiving party receives the ID and/or the retransmission sequence of the data logic channel in the lost frame, and filling the compensation data generated locally in the position of the lost frame.

The method has the technical effects that after retransmission failure occurs in the DigRF interface, the correctness of the data time sequence after the frame is lost can be ensured, performance loss or call drop and the like caused by the traditional method are avoided, and the overall robustness of the system is improved.

Drawings

Fig. 1 is a schematic diagram of the most basic connection between RFIC and BBIC chips defined by the DigRF V4 standard.

Fig. 2 is a schematic diagram of a normal frame structure defined by the DigRF V4 standard.

Fig. 3 is a schematic diagram of the nesting mechanism defined by the DigRF V4 standard.

Fig. 4 is a schematic diagram of the header structure of type one in a normal frame defined by the DigRF V4 standard.

Fig. 5 is a diagram illustrating a case one of the header structures of type two in a normal frame defined by the DigRF V4 standard.

Fig. 6 is a diagram showing a case two of the header structure of type two in a normal frame defined by the DigRF V4 standard.

Fig. 7 is a flowchart of a DigRF retransmission failure processing method proposed in the present application.

Fig. 8 is a schematic diagram of the structure of the payload of the null frame specified in the DigRF V4 protocol.

Fig. 9 is a schematic structural diagram of a load of the null frame proposed in the present application.

Fig. 10 is a schematic diagram comparing a conventional method for DigRF retransmission failure with the method of the present application.

Fig. 11 is a schematic structural diagram of a DigRF retransmission failure processing apparatus according to the present application.

The reference numbers in the figures illustrate: 10 is a detection unit, 20 is a notification unit, and 30 is a compensation unit.

Detailed Description

Referring to fig. 7, a method for handling a DigRF retransmission failure in the present application includes the following steps.

Step S10: the receiver finds that the frame transmitted by the DigRF protocol has retransmission failure, and the receiver sends NACK frame of the retransmission frame to the sender. The retransmission failure means that the receiver finds that an error occurs in a received frame and requires the transmitter to retransmit, and then the receiver finds that the received retransmitted frame is still in error. The frame in which retransmission fails is called a lost frame.

Preferably, the frame transmitted through the DigRF protocol refers to a frame transmitted through a data logical channel of the DigRF protocol.

Step S20: and the transmitting party receives the NACK frame of the retransmission frame and informs the receiving party of the ID and/or retransmission sequence of the data logical channel in the lost frame.

Preferably, in case of only one lost frame, the sender informs only the receiver of the ID of the data logical channel in the lost frame. In the case where the number of lost frames is more than one, for example, in an actual scene, retransmission failure of more than one frame may occur in a short time, and at this time, the transmitter informs the receiver which lost frame is currently described (referred to as retransmission order) and the ID of the data logical channel in the currently described lost frame.

Step S30: the receiving party receives the ID and/or retransmission sequence of the data logic channel in the lost frame, knows the length of the lost frame and the attribution of the lost frame data, and fills the locally generated compensation data in the position of the lost frame.

The sender and the receiver are an RFIC chip and a BBIC chip in the UE respectively; or vice versa.

In step S10, the case where the retransmission fails refers to the following case. First, the receiver finds that an error occurs in a received frame, and the receiver sends a NACK frame to the sender to inform the sender of retransmission. Then, the transmitting side receives the NACK frame, and retransmits the error frame to the receiving side according to the CRI field information contained in the NACK frame. Then, the receiver finds that the received retransmission frame is still wrong, that is, the retransmission fails.

In step S20, the sender may inform the receiver of the ID and/or retransmission order of the data logical channel in the lost frame through various methods. The ID and/or retransmission order of the data logical channel in the lost frame is signalled, for example, by two consecutive empty frames used in the DigRF V4 protocol.

Referring to fig. 8, two consecutive null frames specified in the DigRF V4 protocol are transmitted through the control Logical Channel ICLC (interface control Logical Channel), and the length of the payload of each null frame is fixed to 2 bytes. The first byte is the ICLC ID, fixed at 0x96, where 0x represents a hexadecimal number. The second byte is fixed to 0x 0.

Preferably, in step S20, the transmitter transmits two consecutive null frames to the receiver, and the payload of any one or two null frames includes the ID of the data logical channel of the lost frame. If the header of the lost frame is a type one header, the ID of the data logical channel is recorded only by the DLC _ ID field of the lost frame. If the header of the lost frame is a type two header, the ID of the data logical channel is commonly recorded by the DLC _ ID field and the SDLC _ ID field of the lost frame.

Referring to fig. 9, this is exemplified by the header of the lost frame being type two, and in the payload of any one or two null frames, for example, the contents of the DLC _ ID field of the header of the lost frame are recorded in the first 3 bits of the second byte, and the contents of the SDLC _ ID field of the header of the lost frame are recorded in the last 4 bits of the second byte. If the header of the lost frame is a header of type one, then the last 4 bits of the second byte in fig. 9 are filled with the preset value. Based on the same principle, the retransmission sequence information can be recorded in the load of any one or two empty frames.

In step S30, the receiving side can know the length of the lost frame and the attribution (which cell, antenna and IQ information) of the lost frame data according to the ID of the data logical channel of the lost frame, so that the locally generated compensation data can be filled in the corresponding location. The mapping relation between the ID of the data logical channel of a frame and the length of a corresponding frame of data, the cell for receiving and/or transmitting, the antenna, and the IQ information is configured in advance, so that the length of a lost frame and the attribution of the lost frame of data can be known. The IQ information refers to information of I path and Q path data, and since the communication signal is a complex signal, I path and Q path are divided, which can be understood as real part and imaginary part of a complex number. The compensation data may be a fixed constant, or a locally generated random number, or residual data in an original memory, etc., as desired.

Referring to fig. 10, after DigRF retransmission fails, it is assumed that frame n +1 is a lost frame. The receiver of the existing method does not compensate for the lost frame n +1, and the frame n +2 is located at the position of the frame n +1, so that the correct data is at the wrong position. Once the data timing of the receiving party is wrong, the demodulation and decoding of the subsequent data are completely wrong, and correct receiving and sending can be restored only by restarting. Although the data of the lost frame n +1 can not be recovered, the position of the original lost frame n +1 filled with the locally generated compensation data is used, so that the wrong data is in the correct position, and the accurate time sequence of the subsequent frame can be ensured and the subsequent frame can be correctly received. Meanwhile, the communication system itself has mechanisms such as coding gain and HARQ (hybrid automatic repeat request) combining, so that the data of these lost frames can be recovered by means of decoding and HARQ combining. The method of the present application therefore does not cause significant performance loss, even more so, does not result in dropped calls or more serious system disasters.

Referring to fig. 11, the apparatus for processing a DigRF retransmission failure proposed in the present application includes a detecting unit 10, an informing unit 20, and a compensating unit 30. The detection unit 10 is configured to send a NACK frame of a retransmitted frame to the sender by the receiver when the receiver finds that a retransmission failure occurs in a frame transmitted through the DigRF protocol. The retransmission failure means that the receiver finds that an error occurs in a received frame and requires the transmitter to retransmit, and then the receiver finds that the received retransmitted frame is still in error. The frame in which retransmission fails is called a lost frame. The informing unit 20 is configured to inform the receiving side of the ID and/or the retransmission order of the data logical channel in the lost frame by the sending side after the sending side receives the NACK frame of the retransmission frame. The compensation unit 30 is configured to obtain the length of the lost frame and the attribution of the lost frame data after the receiving side receives the ID and/or the retransmission sequence of the data logical channel in the lost frame, and fill locally generated compensation data in the position of the lost frame.

Compared with a retransmission failure processing mechanism in the original DigRF V4 protocol, the DigRF retransmission failure processing method and the device can not only realize the alarm of retransmission failure, but also ensure the correctness of the data time sequence after the frame is lost, and can avoid the performance loss or call drop and the like caused by the traditional method by combining the coding gain and the HARQ mechanism of a communication system, thereby improving the overall robustness of the system.

The above are merely preferred embodiments of the present application and are not intended to limit the present application. Various modifications and changes may occur to those skilled in the art. Any modification, equivalent replacement, improvement and the like made within the spirit and principle of the present application shall be included in the protection scope of the present application.

Claims

1. A DigRF retransmission failure processing method is characterized by comprising the following steps;

step S10: the method comprises the following steps that a receiver finds that a retransmission failure occurs in a frame transmitted through a DigRF protocol, wherein the retransmission failure refers to the situation that the receiver finds that an error occurs in a certain frame received and requires a sender to retransmit, and then the receiver finds that the received retransmitted frame is still in error; a receiving side sends a NACK frame of a retransmission frame to a sending side; the frame with retransmission failure is called lost frame; the sender and the receiver are an RFIC chip and a BBIC chip in user equipment respectively; or vice versa;

step S20: the sender receives the NACK frame of the retransmission frame, and the sender informs the receiver of the ID and/or retransmission sequence of the data logical channel in the lost frame;

step S30: the receiving party receives the ID and/or retransmission sequence of the data logical channel in the lost frame, knows the length of the lost frame and the attribution of the lost frame data, and fills the locally generated compensation data in the position of the lost frame; the attribution of the lost frame data comprises a cell to which the lost frame belongs, an antenna and IQ information.

2. The method for handling DigRF retransmission failure according to claim 1, wherein in step S10, the frame transmitted via the DigRF protocol is a frame transmitted via a data logical channel of the DigRF protocol.

3. The method for handling DigRF retransmission failure according to claim 1, wherein in step S10, the case where retransmission fails is the following case; firstly, a receiver finds that a certain received frame has errors, and the receiver sends a NACK frame to a sender to inform the sender to retransmit the frame; then, the sender receives the NACK frame and retransmits the error frame to the receiver according to the CRI field information contained in the NACK frame; then, the receiver finds that the received retransmission frame is still wrong, that is, the retransmission fails.

4. The method according to claim 1, wherein in step S20, when there is only one lost frame, the sender only informs the receiver of the ID of the data logical channel in the lost frame;

when the number of the lost frames is more than one, the transmitting side informs the receiving side which lost frame is currently described, i.e. the retransmission order, and the ID of the data logical channel in the currently described lost frame.

5. The method for handling DigRF retransmission failure according to claim 1, wherein in step S20, the sender uses two consecutive empty frames to inform the receiver of the ID and/or retransmission order of the data logical channel in the lost frame; and recording the ID and/or retransmission sequence of the data logical channel of the lost frame in the load of any one or two empty frames.

6. The method for handling DigRF retransmission failures according to claim 5, wherein in step S20, if the header of the lost frame is a type-one header, only the content of the DLC _ ID field of the lost frame is recorded in the payload of the empty frame; if the header of the lost frame is a type two header, the contents of the DLC _ ID field and SDLC _ ID field of the lost frame are recorded in the payload of the empty frame.

7. The method for handling DigRF retransmission failure according to claim 1, wherein in step S30, the compensation data is one or more of a fixed constant, a locally generated random number, or residual data in an original memory.

8. A DigRF retransmission failure processing device is characterized by comprising a detection unit, an informing unit and a compensation unit;

the detection unit is used for sending NACK frame of retransmission frame to the sender by the receiving side when the receiving side finds that the retransmission of the frame transmitted by the DigRF protocol fails; the retransmission failure means that the receiver finds that an error occurs in a received frame and requires the transmitter to retransmit, and then the receiver finds that the received retransmitted frame is still in error; the frame with retransmission failure is called lost frame; the sender and the receiver are an RFIC chip and a BBIC chip in user equipment respectively; or vice versa;

the informing unit is used for informing the ID and/or the retransmission sequence of the data logical channel in the lost frame to the receiving party by the sending party after the sending party receives the NACK frame of the retransmission frame;

the compensation unit is used for acquiring the length of the lost frame and the attribution of the lost frame data after the receiving party receives the ID and/or the retransmission sequence of the data logic channel in the lost frame, and filling locally generated compensation data in the position of the lost frame; the attribution of the lost frame data comprises a cell to which the lost frame belongs, an antenna and IQ information.