CN111800231A

CN111800231A - DigRF retransmission frame identification method and device

Info

Publication number: CN111800231A
Application number: CN202010394770.4A
Authority: CN
Inventors: 檀甲甲; 朱学庆; 陈松
Original assignee: ASR Microelectronics Co Ltd
Current assignee: ASR Microelectronics Co Ltd
Priority date: 2020-05-12
Filing date: 2020-05-12
Publication date: 2020-10-20
Anticipated expiration: 2040-05-12
Also published as: CN111800231B

Abstract

The application discloses a DigRF retransmission frame identification method, which comprises the following steps. Step S10: the receiver finds that the frame received by the DigRF protocol has errors, and the receiver sends a NACK frame to the sender to inform the sender of retransmission; the frame in which the error occurs is called a first transmission frame. Step S20: and the transmitting side receives the NACK frame, retransmits the error frame to the receiving side according to the information of the CRI field contained in the NACK frame, and carries the sequence information of the first transmission frame in the retransmission frame to indicate which frame is retransmitted. Step S30: and the receiver receives the retransmission frame and fills the load of the retransmission frame into a correct position according to the sequence information of the first transmission frame recorded in the retransmission frame. The method and the device can facilitate the receiver to identify which retransmission frame is retransmitted, thereby helping the receiver to avoid the problem of misplacing the retransmission frame and also helping the receiver to judge whether retransmission failure occurs.

Description

DigRF retransmission frame identification 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 conventional DigRF V4 protocol provides that a retransmitted frame can only be identified as a retransmitted frame using the RTI field in the header, but it is not known which frame is retransmitted. If there are multiple lost frames, it can only be according to the logic of losing first and retransmitting first, and the default retransmitted frame received first is the lost first frame. Referring to fig. 7, when the receiver finds that the frames of CRI1 (indicating that the CRI field takes a decimal number of 1) and CRI3 are lost, it will send NACK frame to inform the sender of retransmission. The sender then sends the re-transmitted frames of CRI1 and CRI3 one after the other. The receiver defaults that the retransmitted frame received first is the retransmission of the CRI1 frame, and then the retransmitted frame received is the retransmission of the CRI3 frame. However, if the retransmission of the CRI1 frame is lost, the receiver will need to feed back NACK frame to the sender again according to the rules in the DigRF V4 protocol, and the sender will need to continuously send two empty frames to inform the receiver. In this case, it is easy to occur that the retransmitted frame of CRI3 arrives at the receiver earlier than the two empty frames. The receiver will mistakenly treat the retransmission of the CRI3 frame as the retransmission of the CRI1 to fill in the CRI1 position, thereby causing local data disorder. That is, although the retransmission of CRI3 was successful, the wrong location was filled in, and the retransmission was wasted. For this scenario, if the receiver can identify which frame the retransmitted frame is retransmitted, the retransmitted frame of CRI3 can be put in the correct position. And in case of two-frame empty frame loss indicating retransmission failure, the mechanism can assist in judging the retransmission failure of the CRI1 frame.

As shown above, the conventional DigRF V4 protocol has very limited recognition of the retransmitted frame, and cannot recognize which frame the retransmitted frame is retransmitted, which may cause some performance loss in many scenarios. With the development of 5G and other ultra-high speed communication systems, the occurrence frequency of similar scenes can be greatly improved. Therefore, improving the recognition mechanism of the DigRF retransmission frame can bring a gain to the system performance.

Disclosure of Invention

The technical problem to be solved by the application is to expand on the basis of the digrv 4 protocol and provide a method for identifying a retransmitted frame.

In order to solve the above technical problem, the method for identifying a DigRF retransmission frame provided in the present application includes the following steps. Step S10: the receiver finds that the frame received by the DigRF protocol has errors, and the receiver sends a NACK frame to the sender to inform the sender of retransmission; the frame in which the error occurs is called a first transmission frame. Step S20: and the transmitting side receives the NACK frame, retransmits the error frame to the receiving side according to the information of the CRI field contained in the NACK frame, and carries the sequence information of the first transmission frame in the retransmission frame to indicate which frame is retransmitted. Step S30: and the receiver receives the retransmission frame and fills the load of the retransmission frame into a correct position according to the sequence information of the first transmission frame recorded in the retransmission frame. The core idea of the application is that: the sender carries the sequence information of the first-transmitted frame of the retransmission frame during retransmission, so that the receiver can conveniently identify which frame the retransmission frame is retransmitted to.

Further, in step S20, the order information of the first transmission frame refers to the content of the CRI field of the first transmission frame. This is a preferred example.

Further, when the first-pass frame is a data logical channel, the retransmission frame in step S20 always adopts a type two header, and records the content of the CRI field of the first-pass frame in the second byte of the type two header. This is a first preferred implementation of step S20, and is applicable to the first transmission frame of the data logical channel.

Further, when the first-pass frame is a data logical channel, an Old _ CRI field is set at the last 3 bits of the second byte of the head of type two of the retransmission frame to record the content of the CRI field of the first-pass frame. This is a specific implementation description of the first preferred implementation of step S20.

Further, when the first-pass frame is a data logical channel, if the first-pass frame is a type one header, the SDLC _ ID field of the header of the retransmission frame does not function; if the first-pass frame is a type-two header, the SDLC _ ID field of the header of the retransmission frame duplicates the contents of the SDLC _ ID field of the header of the first-pass frame. The role of the SDLC _ ID field in the retransmission frame in two different cases is explained here.

Further, when the first transmission frame is a control logical channel, if the first transmission frame is a header of type one, the retransmission frame in step S20 adopts a header of type two, and records the content of the CRI field where the first transmission frame occurs in the second byte of the header of type two; if the first-pass frame is a type two header, the retransmission frame in step S20 adds a third byte to the type two header to adopt a three-byte header, and records the content of the CRI field where the first-pass frame occurs in the added third byte. This is a second preferred implementation of step S20, which is applicable to controlling the first pass frame of the logical channel.

Further, when the first transmission frame is a control logical channel, if the first transmission frame is a type one header, an Old _ CRI field is set at the last 3 bits of the second byte of the type two header of the retransmission frame to record the content of the CRI field of the first transmission frame; if the first transmission frame is a header of type two, an Old _ CRI field is set at the last 3 bits of the third byte of the header of the retransmission frame to record the content of the CRI field of the first transmission frame. This is a specific implementation description of the second preferred implementation of step S20.

Further, in step S30, when the receiver receives the first byte of the header of type two of the retransmission frame, it determines that the retransmission frame is the retransmission frame of the data logical channel or the control logical channel according to the contents of the RTI field and the LCI field, and knows the length of the header, so as to obtain the content of the CRI field of the first transmission frame corresponding to the retransmission frame by analyzing the second byte or the third byte; using the CRI information, the receiver fills the payload of the retransmitted frame in the correct location. This is a preferred example.

Further, in step S30, the receiver determines whether a retransmission failure occurred before according to whether there is a frame loss before the CRI information. This indicates that the present application can also be used to determine if a retransmission failure occurs. If the sequence information of the first transmission frame carried in the retransmission frame indicates that no frame is lost before the first transmission frame, the receiver can judge that the retransmission fails. If the sequence information of the first transmission frame carried in the retransmission frame indicates that a lost frame occurs before the first transmission frame, the receiver can determine that the retransmission failure occurs.

The application also provides a device for identifying the DigRF retransmission frame, which comprises a notification unit, a retransmission unit and a filling unit. The notification unit is used for sending a NACK frame to the sender by the receiving party to notify the sending party of retransmission when the receiving party finds that the frame received by the DigRF protocol has errors; the frame in which the error occurs is called a first transmission frame. The retransmission unit is used for retransmitting the error frame to the receiving party according to the information of the CRI field contained in the NACK frame after the transmitting party receives the NACK frame, and the retransmission frame carries the sequence information of the first transmission frame to indicate which frame is retransmitted. The filling-in unit is used for filling the load of the retransmission frame into a correct position according to the sequence information of the first transmission frame recorded in the retransmission frame after the receiving party receives the retransmission frame.

The technical effect obtained by the method and the device can help the receiver to identify which first-transmitted frame the retransmission frame corresponds to, so that the receiver can be helped to avoid the problem of misplacing the retransmission frame, and meanwhile, the receiver can also be helped to judge whether the retransmission failure occurs.

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 schematic diagram of the presence of multiple lost frames.

Fig. 8 is a flowchart of a method for identifying a DigRF retransmission frame according to the present application.

Fig. 9 is a schematic structural diagram of a data logical channel used in the present application as a retransmission frame.

Fig. 10 is a schematic structural diagram of an apparatus for identifying a DigRF retransmission frame according to the present application.

The reference numbers in the figures illustrate: the number 10 is a notification unit, the number 20 is a retransmission unit, and the number 30 is a padding unit.

Detailed Description

Referring to fig. 8, the method for identifying a DigRF retransmission frame provided in the present application includes the following steps.

Step S10: the receiver finds that the frame received by the DigRF protocol has errors, and the receiver sends a NACK frame to the sender to inform the sender of retransmission. The frame in which the error occurs is called a first transmission frame.

Step S20: and the transmitting side receives the NACK frame, retransmits the error frame to the receiving side according to the information of the CRI field contained in the NACK frame, and carries the sequence information of the first transmission frame in the retransmission frame to indicate which frame is retransmitted.

Step S30: and the receiver receives the retransmission frame and fills the load of the retransmission frame into a correct position according to the sequence information of the first transmission frame recorded in the retransmission frame.

Preferably, in step S20, the order information of the first transmission frame refers to the content of the CRI field of the first transmission frame.

When the error-occurred frame is a data logical channel, the retransmission frame in the step S20 employs a type-two header regardless of the content of the DLC _ ID field. The second byte of the header of type two is used to record the content of the CRI field of the frame in which the error occurred.

Please refer to fig. 9, which is an example of the retransmission frame used in the present application as a data logical channel. At the end of the second byte of the head of type two of the retransmission frame, an Old _ CRI field with the length of 3 bits is newly added for recording the content of the CRI field of the frame with errors. If the frame with the error is originally the header of the type one, the SDLC _ ID field of the header of the type two of the retransmission frame is filled with preset contents, for example, all the SDLC _ ID field is filled with the binary number 0, and the SDLC _ ID field does not work at this time. If the frame in error is originally the header of type two, the SDLC _ ID field of the retransmitted frame duplicates the contents of the SDLC _ ID field of the frame in error, when the contents of the SDLC _ ID field and the contents of the DLC _ ID field together indicate the ID of the current data logical channel.

When the retransmission frame format shown in fig. 9 is adopted, in step S30, when the receiving side receives the first byte of the header of type two of the retransmission frame, it is determined that the retransmission frame is the retransmission frame of the data logical channel by analyzing that the RTI field is 1 and the LCI field is 1 at this time, and therefore it can know that the retransmission frame is the header of type two at this time, and thus the content of the CRI field of the first transmission frame corresponding to the retransmission frame can be obtained by analyzing the second byte. With the CRI information, the load of the retransmitted frame can be filled in the correct position. Meanwhile, the receiver can judge whether retransmission fails or not by judging whether frame loss before the CRI information exists or not.

When the frame in which an error occurs is a control logical channel, there are two cases. In the first case, if the error frame is the header of type one, the retransmission frame in step S20 adopts the header of type two, and records the content of the CRI field of the first-transmitted frame in the second byte of the header of type two. At this time, the first byte of the type two header has the same format as the first byte in fig. 5, and the second byte of the type two header removes the SDLC _ ID field on the basis of the second byte in fig. 9. Specifically, an Old _ CRI field is set at the last 3 bits of the second byte of the head of the type two of the retransmission frame, and is used for recording the content of the CRI field of the first transmission frame; the remaining 5 bits have no effect. In the second case, if the frame with the error is the header of type two, the retransmitted frame in step S20 is added with a third byte on the basis of the header of type two, and the header with the length of three bytes is used. The content of the CRI field of the erroneous frame is recorded at this time with the third byte. Of the three-byte-length headers, the first two bytes are, for example, in the same format as shown in fig. 5, and the third byte is, for example, removed from the SDLC _ ID field on the basis of the second byte in fig. 9. Specifically, an Old _ CRI field is set at the last 3 bits of the third byte of the head of the retransmission frame, and is used for recording the content of the CRI field of the first transmission frame; the remaining 5 bits have no effect.

Referring to fig. 10, the apparatus for identifying a DigRF retransmission frame provided in the present application includes a notification unit 10, a retransmission unit 20, and a padding unit 30.

The notification unit 10 is configured to send a NACK frame to the sender by the receiver to notify the sender of retransmission when the receiver finds that the frame received via the DigRF protocol is in error. The frame in which the error occurs is called a first transmission frame.

The retransmission unit 20 is configured to retransmit the erroneous frame to the receiving side according to the information of the CRI field included in the NACK frame after the transmitting side receives the NACK frame, where the retransmission frame carries the sequence information of the first-transmitted frame to indicate which frame is retransmitted.

The filling unit 30 is configured to fill the load of the retransmission frame into a correct position according to the sequence information of the first transmission frame recorded in the retransmission frame after the receiving side receives the retransmission frame.

Compared with the existing DigRF V4 protocol, the DigRF retransmission frame identification method and device provided by the application can help the receiver to identify which first-transmitted frame the retransmission frame corresponds to, thereby helping the receiver to avoid the problem of misplacing the retransmission frame, and also helping the receiver to judge whether the retransmission fails.

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 method for identifying a DigRF retransmission frame is characterized by comprising the following steps;

step S10: the receiver finds that the frame received by the DigRF protocol has errors, and the receiver sends a NACK frame to the sender to inform the sender of retransmission; the frame with errors is called a first transmission frame;

step S20: a sender receives a NACK frame, retransmits the error frame to a receiver according to the information of CRI field contained in the NACK frame, and the retransmission frame carries the sequence information of the first transmission frame to indicate which frame is retransmitted;

2. The method for identifying a DigRF retransmission frame according to claim 1, wherein in step S20, the order information of the first-transmitted frame refers to the content of the CRI field of the first-transmitted frame.

3. The method according to claim 2, wherein when the first-transmitted frame is a data logical channel, the retransmitted frame in step S20 always uses a type two header, and the second byte of the type two header records the content of the CRI field of the first-transmitted frame.

4. The method as claimed in claim 3, wherein an Old _ CRI field is set in the last 3 bits of the second byte of the head of type two of the retransmitted frame, and is used to record the content of the CRI field of the first transmitted frame.

5. The method of claim 3, wherein if the first transmitted frame is a type one header, the SDLC _ ID field of the header of the retransmitted frame is disabled; if the first-pass frame is a type-two header, the SDLC _ ID field of the header of the retransmission frame duplicates the contents of the SDLC _ ID field of the header of the first-pass frame.

6. The method according to claim 2, wherein when the first-transmitted frame is a control logical channel, if the first-transmitted frame is a type one header, the retransmitted frame in step S20 uses a type two header, and records the content of the CRI field of the first-transmitted frame in the second byte of the type two header; if the first-pass frame is a type two header, the retransmission frame in step S20 adds a third byte to the type two header to adopt a three-byte header, and records the content of the CRI field where the first-pass frame occurs in the added third byte.

7. The method as claimed in claim 6, wherein if the first transmitted frame is a type one header, an Old _ CRI field is set in the last 3 bits of the second byte of the type two header of the retransmitted frame for recording the content of the CRI field of the first transmitted frame; if the first transmission frame is a header of type two, an Old _ CRI field is set at the last 3 bits of the third byte of the header of the retransmission frame to record the content of the CRI field of the first transmission frame.

8. The method according to claim 3 or 5, wherein in step S30, when the receiver receives the first byte of the header of type two of the retransmission frame, the receiver determines that the retransmission frame is the retransmission frame of the data logical channel or the control logical channel according to the contents of the RTI field and the LCI field, and knows the length of the header, so as to obtain the content of the CRI field of the first transmission frame corresponding to the retransmission frame by parsing the second byte or the third byte; using the CRI information, the receiver fills the payload of the retransmitted frame in the correct location.

9. The method of claim 8, wherein in step S30, the receiver determines whether a retransmission failure occurred before based on whether there is a frame loss before the CRI information.

10. A DigRF retransmission frame identification device is characterized by comprising a notification unit, a retransmission unit and a filling unit;

the notification unit is used for sending a NACK frame to the sender by the receiving party to notify the sending party of retransmission when the receiving party finds that the frame received by the DigRF protocol has errors; the frame with errors is called a first transmission frame;

the retransmission unit is used for retransmitting the error frame to the receiving party according to the information of the CRI field contained in the NACK frame after the transmitting party receives the NACK frame, and the retransmission frame carries the sequence information of the first transmission frame to indicate which frame is retransmitted;

the filling-in unit is used for filling the load of the retransmission frame into a correct position according to the sequence information of the first transmission frame recorded in the retransmission frame after the receiving party receives the retransmission frame.