A tricky problem concerned with fragmentation and Logical link Layer service.

The following statements are based on DSRC protocol(see the end), however, I'm sure it also fits into other protocol as long as it has following characteristic: The upper layer supports fragmentation but the layer right under it is a stop-wait protocol(one sequence number). ========================================== Background knowledge(you don't need to understand, just for convenience and clarification): RSU: road side unit, a equipment located on the road side. OBU: on-board unit, a equipment located on the cars. DSRC: a protocol used to communicate between OBU and RSU. RSU and OBU both have Layer2(link layer) and Layer7(application layer) entity. Layer7: Application layer which supports fragmentation Layer2: Logical link layer which is a stop-wait protocol with one sequence number. (802.2LLC type3)

Graph Description: RSU OBU

********* ********** *Layer7* *Layer7 ********* ********** *Layer2* *Layer2 ********* ********** *Physical(antenna) Physical(antena) ============================================================= Problem Description: 1, Layer2 is rightly under layer7, layer2 uses a stop-wait protocol, which has one sequence number. Layer7 supports fragmentation. Now there are two peers: RSU and OBU. RSU's Layer7 fragment a PDU into 2 fragments. So layer7 call layer2 primitive to send fragment 1 with sequence number 0. OBU receives fragment 1, and OBU's layer7 finds it's a fragmented PDU, so it waits for fragment2. However, RSU's layer7 won't send fragment2 since RSU's layer2 is waiting for response from OBU(layer2 is a stop-wait protocol). This scenario will lead to deadlock!!!!!!

2, Also, if RSU's layer7 sends a non-fragmented PDU to OBU, and OBU needs to send back 2 fragments, this will also leads to incorrect sequence number maintenance since Layer2 is a stop-wait protocol with one sequence number maintained.

Am I right? How to deal with such problem?

================================================================ Related resources:

1, 802.2 Standard. (the layer2 uses type3 service of LLC) 2, STF282(DSRC Conformance Testing in support of Interoperability)
formatting link
DSRC Home:
formatting link

Thanks very much for your attention!!!! Regards. Tom

Reply to
lander
Loading thread data ...

FWIW, I am very familiar with this architecture, and am currently working on a number of issues in VII (Vehicular Information Infrastructure), which uses DSRC in this manner.

First of all, LLC Type 3 is not really a "stop-and-wait" protocol. It is an acknowledged *connectionless* protocol; connectionless means no guarantee of delivery. The acknowledgment (ACK) tells the client whether its peer has received the message, but there is no retransmission by LLC if the ACK is not received. This is fundamentally different from a reliable-delivery, stop-and-wait protocol where the layer will retransmit in the event of a missing frame. Whether there is one sequence number, or more than one, is solely a tradeoff between performance (better throughput with more than one sequence number) and buffering requirements (more sequence numbers means more frames must be stored pending possible retransmission.

Second, under the DSRC architecture shown, the Application protocol must be responsible for BOTH fragmentation (if desired) and reliable delivery (i.e., retransmission of frames in the event of non-acknowlegment). LLC-3 does not perform either of these functions.

No. Upon receiving the first fragment, LLC-3 in the OBU will issue an ACK. Remember, LLC is unaware that this frame is a fragment of a larger message, and deals only with one frame at a time. Assuming it is received properly, the LLC entity within the OBU will issue the LLC ACK, and pass the received frame up to the Application entity within the OBU. The Application entity *does* understand fragmentation, and therefore must wait for the second fragment before acting on the received message.

Upon receipt of the ACK from the OBU's LLC-3 entity, the RSU will then send the next frame in its transmit queue, which is presumably the next fragment. The process repeats: the second fragment is sent, the OBU's LLC issues an ACK, and the fragment is passed to the Application within the OBU. The Application can now reconstruct the complete message and take appropriate action.

Note that both fragments will have the same LLC "sequence number" (in your terms); they will have different sequence indicators at the Application layer, however, since that layer must distinguish between the two portions for transmission and reassembly.

In the event that a frame is not properly received (either fragment), there will be no LLC ACK issued. The Application entity within the RSU will time out, and retransmit the fragment. Under your scenario (i.e., only one frame can be outstanding at any given time), the Application must try to send each fragment in order; the entire system "waits" for the time-out and retransmission of each frame until success (or the entire operation is cancelled).

This scenario is identical to the first one, except with the roles reversed. Remember, it is the Application (not LLC) that is controlling, and responsible for, both fragmentation and retransmission in the event of non-acknwledgment by the partner device.

-- Rich Seifert Networks and Communications Consulting 21885 Bear Creek Way (408) 395-5700 Los Gatos, CA 95033 (408) 228-0803 FAX

Send replies to: usenet at richseifert dot com

Reply to
Rich Seifert

Thanks very much for replying!!!

I'm not sure which standard you refer to, I'm refering to DSRC european stanadard. However, the layer2 should be the same with what you refer to, i.e connectionless-acknowledged(LLC-3). I'm not sure about whether Layer7 is the same.

Now I've got several problems below:

1, Nevertheless, you said that upon receipt of RSU's command, OBU's LLC should respond with an ACK immediately, but the standard doesn't specify this.

2, You said that Upon receipt of the OBU's LLC-3 ack, Layer7 sends the next fragment, how should RSU's LLC informs RSU's Layer7? The standard doens't seem to specify this kind of primitive.

3, You said the layer7 should be in charge of restrasmitting commands, the standard doesn't speicify it too.

4, And, I've looked log files of layer2&&layer7 of the current implementations(i.e QFree), there is no independent ack from OBU's LLC if the request is a "Data Exchange"(P=1). In the case of "Data Transmitting"(P=0), it is okay!!!

!!What's most tricky here is point 4. !!

Thanks in advance for replying!!!

Reply to
lander

It doesn't matter whether the two systems use the identical Application protocol; whatever protocol is used, it must assume responsibility for both fragmentation and reliable delivery in your stated architecture.

Yes, it does. This is covered by the LLC standard (IEEE 802.2), not the DSRC standard.

Again, check the 802.2 LLC-3 specification; all of the layer primitives are provided there.

The standard does not state this because it does not have to. *IF* your application requires reliable delivery (i.e., retransmission in the event of a discarded frame), then the application must provide this function, since it is clearly not provided by the lower layers. Note, however, that this is an *application* requirement, not related to the architecture.

If the application does *not* require reliable delivery (many such applications exist--think of idempotent routing protocols), then the application need not retransmit in the event of a discarded frame. That is, an application that can tolerate occasional loss can ignore retransmissions; an application that cannot tolerate such losses must compensate by retransmitting. It's all up to the application.

I have no idea what you are talking about on this point. I am not familiar with the implementation you describe.

-- Rich Seifert Networks and Communications Consulting 21885 Bear Creek Way (408) 395-5700 Los Gatos, CA 95033 (408) 228-0803 FAX

Send replies to: usenet at richseifert dot com

Reply to
Rich Seifert

Thanks very much for your reply.

Now, the problem can be concluded as such:

(For clarification: RSU can only send command(i.e request with respect to Layer7), OBU can only send response))

1, From my understanding, when the OBU's LLC-3 receives a command from RSU to request a response from OBU, it doesn't send back the ack immediately, instead, it will pass the LLC's SDU up to OBU's Layer7 for further processing, then OBU's LLC-3 waits for OBU's layer7 to pass down a response(L7 uses the DL-REPLY-UPDATE primitive) which will then be transmitted by OBU's LLC immediately (and the ack is sent, i.e piggybacked by the LLC SDU).

2, But from your description and the LLC-3 spec, the OBU's LLC-3 will send back the ack immediately upon receipt of RSU's LLC-3 command. If this is true, the OBU will send two frames for a independent request from RSU, one is the 'ack', the latter is the actual 'response'. In order to send the latter one, the OBU has to request a new window(timeslot) since the previous 'ack' has used the window allocated by the RSU's LLC-3 command. Or if the window allocated hasn't expired before the latter actual 'response' is prepared, it will be transmitted with the 'ack' in the same window.

****I'm sorry if the text decribed has something you're not familiar with, especially the window(timeslot) which is stated in the MAC layer of DSRC)***

What do you think of point1 vs 2?

Thanks in advance!!! ^_^

Reply to
lander

In general, this statement is not true. The RSU and OBU are peers; they must be able to communicate equally between themselves. While the

*application* may invoke a command-response behavior, the LLC-3 entities are identical and symmetrical.

This is not true. The LLC ACK is sent immediately, by LLC, without any intervention or action on the part of the application. There may also be an "application ACK", but this looks to the OBU's LLC like any other application message (and indeed, it will be ACK'ed by the RSU in the other direction).

You should carefully read the LLC specification to see how the layer entity operates.

Correct. It is ACK'ing LLC's receipt of the frame, not the application's receipt of the command message.

Correct; this is how it should work.

Correct. As I said, the response from the application in the OBU appears to the network as being no different from the original command issued from the RSU; they are application peers.

The OBU cannot "hold up" progress on the network for the length of time that it will take for the application to process the command and issue some command-dependent response. Depending on the implementation (e.g., the speed of processing in the OBU, buffer copies, software interrupts, etc. the length of time may be quite long; in any case, it is generally unpredictable and will vary from vehicle to vehicle.

This should never occur; the LLC entity will likely not even pass up the received command to the application before it issues its own ACK.

-- Rich Seifert Networks and Communications Consulting 21885 Bear Creek Way (408) 395-5700 Los Gatos, CA 95033 (408) 228-0803 FAX

Send replies to: usenet at richseifert dot com

Reply to
Rich Seifert

Thanks.

In DSRC european standard, there are only 3 kinds of primitives associated with LLC-3:

1, DL-DATA-ACK.request: Only on RSU side. To transmit data to OBU only.(OBU just sends back ack) 2, DL-REPLY.request: Only on RSU side. To exchange data with OBU(OBU needs send back LLC SDU if available). 3, DL-REPLY-UPDATE.request: Only on OBU side. From OBU's Layer7 to LLC to *prepare* data to send later.

More questions:

1, So if the OBU's LLC-3 receives the command from RSU, it will issue an ACK first. As for the second "actual response", the only primitive OBU's layer7 can use is "DL-REPLY-UPDATE.request", so the response can only be just pended on the OBU side for RSU to request it later, which means RSU's L7 has to retransmit the previous command later to get the second "actual response". Is it right?! If it's not right, how it should proceed?

2, If L7 is responsible for retranmission , I don't see any use of LLC retransmission here which has been expressed in 802.2 LLC-3 std and DSRC Euro std. Why not use only LLC-1 since the retranmission is not that needed?! And, if LLC retranmission is that needed, when?!

Thanks very much! ^_^

Reply to
lander

It should proceed to repair the flawed architecture you describe. There is no good reason to prohibit the OBU from sending unsolicited messages to the RSU; we impose no such limitation in (U.S.) VII. What you describe is an asymmetrical implementation of LLC, which is not what is specified in the international (ISO) LLC standard; i.e., what you describe is *not* LLC-3, but a proprietary modification of that standard. I would fix the system design, rather than ponder on how to work around its flaws.

You seem to think that 802.2 LLC-3 includes the facility to retransmit frames in the event of errors. It does not; LLC-2 (connection oriented service) is the only LLC variant that performs reliable delivery with retransmission.

LLC-1 does not even provide a low-level indication (i.e., the ACK) that the frame was received at all. The application would have to include an application-layer ACK in order to know whether to retransmit. By using LLC-3, you potentially (i.e., in minimal systems) eliminate the need for the Application ACK. Furthermore, LLC-3 does permit the station to pre-load the LLC with a response to an anticipated future message (Request-With-Response), which can streamline certain process-control applications. However, both LLC-1 and LLC-3 are connectionless (i.e., no guarantee of delivery) systems, and do not perform either error recovery or flow control.

-- Rich Seifert Networks and Communications Consulting 21885 Bear Creek Way (408) 395-5700 Los Gatos, CA 95033 (408) 228-0803 FAX

Send replies to: usenet at richseifert dot com

Reply to
Rich Seifert

Thanks again.

1, LLC-3 does have retransmission capability which is described in the LLC-3 procedure: "Sending ACn Commnand PDUs". After sending the ACn Command, it starts an ack timer, it it times out, ACn command would be retransmitted and also does the corresponding response. When this facility is used in the DSRC?!

2, And, I'm also not clear about the CCCCRRRR field decribed in LLC spec. Especially the UN/RS/UE/IT/IP etc....It seems LLC spec is the only place where these fields are used, how should be dealt with in DSRC spec exactly??!!

Many thanks.

Reply to
lander

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.