CN111008172A

CN111008172A - Interface communication protocol stack

Info

Publication number: CN111008172A
Application number: CN201911251308.2A
Authority: CN
Inventors: 王楠楠; 黄小鹏
Original assignee: Eastcompeace Technology Co Ltd
Current assignee: Eastcompeace Technology Co Ltd
Priority date: 2019-12-09
Filing date: 2019-12-09
Publication date: 2020-04-14

Abstract

The application discloses interface communication protocol stack includes: a start field, an information field, and a termination field; the start field includes a byte NAD for identifying transmission and reception of the data frame, a protocol control byte PCB for identifying a type of the data frame, and a byte LEN for recording the number of bytes in the information field; the termination field includes check bytes EDC for carrying error detection codes; NAD occupies 1 byte, PCB occupies 1 byte, LEN occupies 2 bytes, information field occupies 0 to 65534 bytes, and EDC occupies 2 or 4 bytes. The interface communication protocol stack defines the sending and receiving bytes for identifying the data frame, the bytes for identifying the type of the data frame, the bytes for transmitting information and the bytes for error detection and verification, unifies the content specification of the protocol stack, has the function of error detection and verification, improves the reliability of interface protocol communication, and solves the technical problems that the prior art does not have perfect protocol stack definition on SPI and I2C interface communication and the communication reliability is lower.

Description

Interface communication protocol stack

Technical Field

The application relates to the technical field of interface communication, in particular to an interface communication protocol stack.

Background

With the development of the field of internet of things, the application range of the SE password security module is more and more extensive, and the SE password security module is applied to vehicle-mounted terminals, internet of things devices, video terminal watches and other internet of things terminals, and these terminals generally use SPI and I2C interfaces for communication, and at present, no perfect protocol stack definition exists on SPI and I2C interface communication, and the communication reliability is low.

Disclosure of Invention

The application provides an interface communication protocol stack for solve prior art and do not have perfect protocol stack definition in SPI, I2C interface communication, the lower technical problem of communication reliability.

In view of this, the present application provides an interface communication protocol stack, which includes: a start field, an information field, and a termination field;

the start field comprises a byte NAD for identifying the sending and receiving of the data frame, a protocol control byte PCB for identifying the type of the data frame and a byte LEN for recording the number of bytes in the information field;

the termination field includes check bytes EDC for carrying error detection codes;

the NAD occupies 1 byte, the PCB occupies 1 byte, the LEN occupies 2 bytes, the information field occupies 0 to 65534 bytes, and the EDC occupies 2 or 4 bytes.

Optionally, the NAD, the PCE, and the LEN are sequentially set in the start field.

Optionally, the EDC carries an error detection code that is a cyclic redundancy check code.

Optionally, the data frame type identified by the PCB includes: a transport information block, a transport control block, or a transport acknowledgement block;

the information field is present in the transport information block or the transport acknowledgement block;

when the information field is present in the transport information block, the information field is used to carry application information;

the information field is used to carry non-application information when the information field is present in the transport acknowledgement block.

Optionally, the coding rule of the LEN is:

when the value of the LEN is 00, the information field does not exist in an interface communication protocol stack;

when the value of the LEN is any value from 01 to FFFF, the information field exists in an interface communication protocol stack, and the number of bytes appearing in the information field is the value of the LEN.

Optionally, the character latency of the interface communication protocol stack is not less than 12etu, and the block protection time is not less than 22 etu.

Optionally, the block latency of the interface communication protocol stack is a maximum delay between a starting edge of a last character of a received block and a starting edge of a first character of a next block sent out.

Optionally, the transmission information block is an I block, the transmission control block is an R block, and the transmission acknowledgement block is an S block;

the transmission format of the I block is I (N (S)) and M, wherein N (S) is the sending sequence number of the block, and M is additional data;

the transmission format of the R block is R (N (R)), wherein N (R) is the number of the expected transmission information block;

the transmission format of the S block is as follows:

s (RESYNCH request) is an S block for requesting resynchronization, S (RESYNCH response) is an S block for requesting resynchronization, S (IFS request) is an S block with the maximum length of an information field, S (IFS response) is an S block with an information field, S (ABORT request) is an S block for requesting link abandonment, S (ABORT response) is an S block for requesting link abandonment, S (WTxrequest) is an S block for requesting wait time extension, and S (WTX response) is an S block for requesting wait time extension.

Optionally, the interface communication protocol stack satisfies a protocol rule for error-free operation;

the protocol rules for error-free operation include:

rule 1: the interface equipment sends the 1 st I block or S block;

rule 2.1: i (na(s),0) sent by a is acknowledged by I (nb(s), M) sent by B in order to send application data and indicate readiness to receive the next I block from a;

rule 2.2: i (na(s), sent by a, 1) is confirmed by R (nb (R), sent by B [ where nb (R) is not equal to na(s) ], indicating that the received block is correct and ready to receive the next I block from a;

rule 3: if the ICC requires more BWT to process a previously received I-block, it sends s (wtx request), where INF carries a byte encoding a binary integer times the value of BWT, the interface device should acknowledge s (wtx response) with the same INF, the allocated time starting at the beginning edge of the last character of s (wtx response);

rule 4: the ICC sends s (ifs request) indicating a new IFSC it can support, the interface device should acknowledge s (ifs response) with the same INF, if no more IFSCs are indicated by another s (ifsrrequest), the IFD considers the new IFSC to be valid, and the IFD sends s (IFD request) indicating a new IFSD it can support. The ICC should acknowledge with s (ifs response) with the same INF, and consider the new IFSD valid when no more IFSDs are indicated by another s (ifs response);

rule 5: a link is indicated by M bits, where I (N(s),0) is a block NOT on the link or the last block in the link, I (N(s),1) is a part of the link and should be followed by at least one linked block, R (N (R)) requests transmission of the next linked I block I (N(s) ═ N (R), …, and acknowledges receipt of the linked I block I (NOT N (R), 1).

Optionally, the interface communication protocol stack satisfies an error handling protocol rule;

the error handling protocol rules include:

rule 6: s (resynch request) can only be sent by IFD to achieve resynchronization and to reset the communication parameters of the protocol to the initial values of the parameters;

rule 6.1: if the receiver detects loss of synchronization, the receiver withdraws the right to transmit after the quiet time on the I/O is greater than (the greater of) the CWT or BGT;

rule 6.2: s (RESYNCH request) is responded by S (RESYNCD response) from ICC;

rule 6.3: after the IFD has received the S (RESYNCH response), the protocol is started;

rule 6.4: after IFD fails to send s (resynch request) continuously for a maximum of three times to achieve the desired resynchronization, it resets the ICC;

rule 6.5: when s (resynch request) is received, it is assumed that no earlier sent block was received;

rule 7.1: when a received block is invalid or BWT timeout (of IFD) occurs after an I block is sent, sending an R block, using n (R) of the R block to request the expected I block that satisfies n(s) ═ n (R);

rule 7.2: when a received block is invalid or a BWT timeout (of IFD) occurs after transmitting one R block, the R block is retransmitted;

rule 7.3: when the response received after transmitting S (… response) is not S (… response) or BWT timeout (IFD only) occurs, the S (… request) is retransmitted, and when the block received after transmitting S (… response) is invalid or BWT timeout (IFD only) occurs, the R block is retransmitted;

rule 7.4.1: after no error-free block is received at the beginning of the protocol, the IFD tries two more times in succession before resetting or deactivating the ICC;

rule 7.4.2: during the protocol, if the IFD does not receive a block without error, two retries are continued up to two times before sending s (resynchrequest);

rule 7.4.3: if the ICC does not receive an error-free block after two consecutive attempts, the reception mode is maintained;

rule 7.5: after the protocol starts, the card reacts by sending R (0) when it receives the 1 st invalid block;

rule 7.6: if the 1 st block transmitted by IFD does not respond within BWT, IFD transmits R (0);

rule 8: when receiving the invalid block after the ICC sends S (IFS request), in order to lead out S (IFSresponse), the ICC retransmits 1S (IFS request) at most, and after failing for the 2 nd time, the ICC keeps in a receiving mode;

rule 9: the link abandonment should be initiated by the sender or receiver of the link sending s (abort request) which is answered by s (abort response), and whether an R block can be sent later depends on whether it is necessary to restore the right to send.

According to the technical scheme, the embodiment of the application has the following advantages:

in this application, an interface communication protocol stack is provided, including: a start field, an information field, and a termination field; the start field includes a byte NAD for identifying transmission and reception of the data frame, a protocol control byte PCB for identifying a type of the data frame, and a byte LEN for recording the number of bytes in the information field; the termination field includes check bytes EDC for carrying error detection codes; NAD occupies 1 byte, PCB occupies 1 byte, LEN occupies 2 bytes, information field occupies 0 to 65534 bytes, and EDC occupies 2 or 4 bytes. The interface communication protocol stack defines the sending and receiving bytes for identifying the data frame, the bytes for identifying the type of the data frame, the bytes for transmitting information and the bytes for error detection and verification, unifies the content specification of the protocol stack, has the function of error detection and verification, improves the reliability of interface protocol communication, and solves the technical problems that the prior art does not have perfect protocol stack definition on SPI and I2C interface communication and the communication reliability is lower.

Drawings

Fig. 1 is a block format structure diagram of an interface communication protocol stack according to an embodiment of the present application.

Detailed Description

In order to make the technical solutions of the present application better understood, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.

To facilitate understanding, referring to fig. 1, an embodiment of an interface communication protocol stack provided by the present application includes a start field, an information field, and a termination field; the start field includes a byte NAD for identifying transmission and reception of the data frame, a protocol control byte PCB for identifying a type of the data frame, and a byte LEN for recording the number of bytes in the information field; the termination field includes check bytes EDC for carrying error detection codes; NAD occupies 1 byte, PCB occupies 1 byte, LEN occupies 2 bytes, information field occupies 0 to 65534 bytes, and EDC occupies 2 or 4 bytes.

It should be noted that bytes of the information field are denoted by IFS, and the interface communication protocol stack in the embodiment of the present application is a block transport protocol stack, and the block transport format is as shown in fig. 1, where NAD is used to identify transmission and reception of a data frame and also serves as a header identification of the data frame, and when HD is transmitted to SE, NAD is 0x21, and when SE is transmitted to HD, NAD is 0x 12. The PCB is a protocol control byte and is used for identifying the type of the data frame, and the data frame is defined to comprise three types: the I block is a transmission information block, the S block is a transmission control block, and the R block is a transmission confirmation block.

The coding format of the I block is:

wherein the content of the first and second substances,

b8 … … … … … … … 0 (PCB of I block);

b7 … … … … … … … sending sequence number N (S);

b6 … … … … … … … represents the M bit;

b5-b4-b3-b2-b1…...RFU。

the coding format of the R block is:

b8-b7 … … … … … … 10 (PCB of R block);

b6-b5-b4-b3-b2-b1：

0-N (R) -0000 … … …. error free;

0-N (R) -0001 … … … EDC or character parity error; 0-N (R) -0010 … … … other errors;

other values … … … … ….. RFU.

The coding format of the S block is as follows:

b8-b7 … … … … … … 11 (PCB of S-block);

b6-b5-b4-b3-b2-b1 … … … … … (b6 is the response bit)

000000 … … … … … … RESYNCH request;

a 100000 … … … … … ….. RESYNCH response;

000001 … … … … … ….. IFS request;

an IFS response;

an ABORT request 000010 … … … … … …;

an ABORT response;

000011 … … … … … …. WTX request;

100011 … … … … … …. WTX response;

000100 … … … … … …. CPP request;

CPP response;

001111 … … … … … ….. SWR request;

101111 … … … … … ….. SWR response;

RFU, any other value … … … ….

LEN represents the number of bytes present in the information field of the block, and the encoding format is:

- "00" indicates that no information field exists;

any value of-01 to FFFF indicates the number of bytes present in the information field.

The use of INF depends on the type of block:

-when INF is present in an I-block, INF carries application information;

-INF is not present in the R block;

-when INF is present in the F block, INF carries non-application information.

The EDC in the embodiment of the present application uses a cyclic redundancy check CRC, which consists of two or four bytes.

The protocol parameters in the embodiments of the present application are defined in the CPP as follows:

link layer parameters

Subclass of them	Length of	Description of the invention
			BWT	2	Block wait time (ms)
IFSC	2	Maximum Length of SE information Domain (byte)

I2C interface parameters

SPI interface parameters

The minimum value of the character latency CWT is equal to 12 etu.

The block latency (BWT) is defined as the maximum delay between the starting edge of the last character of a block received by the card and the starting edge of the first character of the next block sent by the card.

The Block Guard Time (BGT) is defined as the minimum delay between the starting edges of two consecutive characters sent in opposite directions, which should be 22etu at minimum.

The linking function allows the IFD or ICC to transmit information longer than the IFSC or IFSD.

The protocol description of the I block is expressed as:

I(N(S),M)

i block, where N (S) is the transmission sequence number of the block, M is additional data

Na(S),Nb(S)

I-block transmission sequence number, with subscripts a and B added to distinguish the source points a and B.

The protocol description of the R block is expressed as:

R(N(R))

r blocks, where n (R) is the number of desired I blocks.

The protocol description of the S block is expressed as:

(RESYNCH request) for resynchronizing the S block;

s (RESYNCH response) recognizes the resynchronized S block;

s (IFS request) S block with maximum length of information field;

s (IFS response) S block of IFS;

(ABORT request) for the S block of link abandonment;

s (ABORT response) affirming the S block of the link abandoning;

(WTX request) to obtain the S block with extended waiting time;

s (WTX response) S block for recognizing the waiting time expansion.

The interface communication protocol stack meets the protocol rule of error-free operation;

protocol rules for error-free operation include:

rule 1: the interface equipment sends the 1 st I block or S block;

The interface communication protocol stack meets the error handling protocol rule;

the error handling protocol rules include:

receiving an invalid block-e.g.:

a character parity error;

EDC error;

invalid PCBs (caused by unknown coding);

invalid LEN (transmission error or incompatibility with block type or incompatibility with IFSC or IFSD);

loss of synchronization due to inconsistency in the values and block lengths indicated by the LEN;

after sending S (… request), no relevant S is received (… response).

rule 6.2: s (RESYNCH request) is responded by S (RESYNCD response) from ICC;

There is provided an interface communication protocol stack comprising: a start field, an information field, and a termination field; the start field includes a byte NAD for identifying transmission and reception of the data frame, a protocol control byte PCB for identifying a type of the data frame, and a byte LEN for recording the number of bytes in the information field; the termination field includes check bytes EDC for carrying error detection codes; NAD occupies 1 byte, PCB occupies 1 byte, LEN occupies 2 bytes, information field occupies 0 to 65534 bytes, and EDC occupies 2 or 4 bytes. The interface communication protocol stack defines the sending and receiving bytes for identifying the data frame, the bytes for identifying the type of the data frame, the bytes for transmitting information and the bytes for error detection and verification, unifies the content specification of the protocol stack, has the function of error detection and verification, improves the reliability of interface protocol communication, and solves the technical problems that the prior art does not have perfect protocol stack definition on SPI and I2C interface communication and the communication reliability is lower.

The above embodiments are only used for illustrating the technical solutions of the present application, and not for limiting the same; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some technical features may be equivalently replaced; and such modifications or substitutions do not depart from the spirit and scope of the corresponding technical solutions in the embodiments of the present application.

Claims

1. An interface communication protocol stack, comprising: a start field, an information field, and a termination field;

2. The interface communication protocol stack of claim 1 wherein the NAD, the PCE, and the LEN are sequentially set in the start field.

3. The interface protocol stack of claim 1 wherein the EDC carries an error detection code that is a cyclic redundancy check code.

4. The interface protocol stack of claim 1 wherein the PCB-identified data frame type comprises: a transport information block, a transport control block, or a transport acknowledgement block;

5. The interface communication protocol stack of claim 1, wherein the coding rule of the LEN is:

6. The interface communication protocol stack of claim 1 wherein the character latency of the interface communication protocol stack is not less than 12etu and the block guard time is not less than 22 etu.

7. The interface communication protocol stack of claim 1 wherein the block latency of the interface communication protocol stack is a maximum delay between a starting edge of a last character of a received block and a starting edge of a first character of a next block sent.

8. The interface protocol stack of claim 4 wherein the transport information block is an I block, the transport control block is an R block, and the transport acknowledgement block is an S block;

the transmission format of the S block is as follows:

s (RESYNCH request) is an S block for requesting resynchronization, S (RESYNCH response) is an S block for requesting resynchronization, S (IFS request) is an S block with the maximum length of an information field, S (IFS response) is an S block with an information field, S (ABORTrequest) is an S block for requesting link abandonment, S (ABORT response) is an S block for requesting link abandonment, S (WTX request) is an S block for requesting wait time extension, and S (WTX response) is an S block for requesting wait time extension.

9. The interface communication protocol stack of claim 8 wherein the interface communication protocol stack satisfies protocol rules for error-free operation;

the protocol rules for error-free operation include:

rule 1: the interface equipment sends the 1 st I block or S block;

rule 4: the ICC sends s (ifs request) indicating a new IFSC it can support, the interface device should acknowledge s (ifs response) with the same INF, the IFD considers the new IFSC valid when no more IFSCs are indicated by another s (ifs request), and the IFD sends s (IFD request) indicating a new IFSD it can support. The ICC should acknowledge s (ifs response) with the same INF, and consider the new IFSD valid when no more IFSDs are indicated by another s (ifsrequest);

10. The interface communication protocol stack of claim 9 wherein the interface communication protocol stack satisfies an error handling protocol rule;

the error handling protocol rules include:

rule 6.2: s (RESYNCH request) is responded by S (RESYNCD response) from ICC;

rule 8: when receiving the invalid block after the ICC sends S (IFS request), in order to lead out S (IFS response), the ICC retransmits 1S (IFS request) at most, and after failing for the 2 nd time, the ICC keeps in the receiving mode;

rule 9: the link abandonment should be initiated by the sender or receiver of the link sending s (abort request) which is answered by s (abort response) and whether an R block can be sent later depends on whether it is necessary to restore the right to send.