Bluetooth

Logical Link Control and Adaptation Protocol (L2CAP) Part D Version 1.0B

1. Because configuration request and disconnection request can be initiated at both sides, it is very confusing for the SDL program to use the source CID and destination CID, it is suggested that only local CID (LCID) and remote CID (RCID) are used. Related to local device, each message specifies LCID; related to remote device, each message specifies RCID, and vice versa. Additionally, if the sending message specifies LCID (or RCID), the corresponding received message specifies RCID (or LCID).
2. When receiving an L2CA_ConnectReq message, L2CAP should first determine whether a physical link to the remote device does exist or not. If not, an LP_ConnectReq message should be sent to request the lower protocol to create a connection. This is missing in Table 3.1.
3. Currently there is no L2CAP_CmdReject message described in Table 3.1. In a real implementation, this message can be definitely determine according to the real situation. In our SDL program, because there is no bit error taken place during message transmission between two processes for SDL simulation and validation, therefore there does not exist invalid CID reject reason, and also there is no way to know whether the L2CAP packet exceeds the receiver MTU. In order to simulate these two reject reasons, we use "any" condition to create the L2CAP_CmdReject message in SDL program. We assume that there only exists invalid CID reject reason for connection and disconnection request, if any; there may exist invalid CID and message MTU exceeded reject reasons for configuration request. For general reject reason, i.e. command is not understood, we use L2CAP_Unknown_Command message to represent it. Note that, it is obvious that every message sent by local device can be received by remote device in SDL program.
4. When receiving an LP_ConnectInd message, L2CAP should send back a positive response (LP_ConnectRsp) or a negative response (LP_ConnectRspNeg) to the lower layer and mark the physical link established or not established. This is missing in Table 3.1.
5. As for configuration flush timeout and link timeout, two timers Flush and Link are defined for L2CAP data. When receiving L2CA_DisconnectReq, L2CAP_DisconnectReq, or LP_DisconnectInd messages and L2CA_ConfigReq, L2CAP_ConfigReq messages in the OPEN state, these two timers should be first disabled, if any. Additionally, when receiving L2CA_DisconnectReq or L2CAP_DisconnectReq, L2CAP should first disable RTX timer, if any. When receiving an LP_DisconnectInd at any time, L2CAP should also disable RTX or ERTX timer, if any. This is missing in Table 3.1.
6. Lower layer LP_DisconnectInd message's receiving incurs upper layer L2CA_DisconnectInd message and returns the local CID to the free pool, and should be initiated at both devices at the same time, but there is no mechanism to guarantee it. Currently L2CAP specification only specify it at one device and SDL can only simulate it in one process at one time, which incurs many state collisions.
7. Currently, L2CAP only specify L2CA_ConnectRsp for success or refused, it is possible for L2CAP still to receive L2CA_ConnectRsp for pending because of authentication, or authorization, or other reasons. This is missing in Table 3.1.
8. L2CAP may still receive L2CAP_ConnectReq before getting back response in W4_L2CA_CONNECT_RSP state. This happens for two cases:
   1) If the local device sends an L2CAP_ConnectReq message and receives back an L2CAP_ConnectRspPnd message, the RTX timer is disabled and the ERTX timer is enabled, implying that remote device is in W4_L2CA_CONNECT_RSP state. Later on if the ERTX timer expires, the L2CAP_ConnectReq message is resent.
   2)If the local device sends an L2CAP_ConnectReq message and starts the RTX timer, the remote device receives it, but does not send the L2CAP_ConnectRsp message yet, implying that the remote device is in W4_L2CA_CONNECT_RSP state. Then the RTX timer expires, the local device resends the L2CAP_ConnectReq message.
9. When receivng a positive L2CAP_ConnectRsp message, L2CAP needs to disable the associated ERTX timer too, if any. After sending the L2CAP_ConnectReq message, if continuously receiving a L2CAP_ConnectRspPnd message and the ERTX timer is reenabled, it needs to determine the maximum receiving number. If exceeding, L2CA_ConnectCfmNeg message is sent and the state is changed into CLOSED. This is missing in Table 3.1.
10. If both devices initiate the L2CA_ConnectReq message at the same time, the state collision will take place because only one state machine is considered for current SDL program, it is suggested that each CID (higher level application) should have its own state machine running separately.
11. Similar to the L2CA_ConnectReq message, when receiving an L2CA_ConfigReq message, L2CAP should first determine whether the service requested is best effort or guaranteed, if it is guaranteed, then the LP_QoSReq message should be sent to request the lower protocol to accommodate the particular QoS parameter set. Corresponding to this LP_QoSReq, LP_QoSCfm is defined in SDL program, including positive or negative confirmation. This is missing in Table 3.1.
12. L2CA response message's receiving should be normally after sending L2CA indication message, especially for L2CA_ConfigRsp in the CONFIG state, otherwise there is no sense for receiving this message. In a real implementation, this depends on the upper layer or the host. This is missing in Table 3.1.
13. The use of the C flag is not defined in Table 3.1, but is in this SDL program.
14. Because there may exist multiple L2CAP_ConfigReq messages for one side, in order to transfer from CONFIG to OPEN state, when receiving L2CA_ConfigRsp and L2CAP_ConfigRsp, the determination conditions are the following:
    * If all outstanding L2CAP_ConfigReq messages for local device have received positive responses;
    * If all L2CAP_ConfigReq messages for remote device have been received and positively responded to.
    Additionally, L2CAP needs to receive all L2CA_ConfigRsp and L2CAP_ConfigRsp messages, because there may also exist multiple L2CAP_ConfigReq messages for remote device and local device.
15. The L2CAP_ConfigRsp and L2CAP_ConfigRspNeg messages are received for success and reject results, according to Figure II of Appendix A, other L2CAP_ConfigRsp messages should be received for unacceptable parameters and unknown options results. This is missing in Table 3.1.
16. When receiving a L2CA_DataWrite, two timers, Flush and Link for L2CAP data, are enabled. When the Flush timer expires, L2CAP flushs the data packet; for Link timer expiration, L2CAP sends L2CA_DisconnectInd to the upper layer. This is missing in Table 3.1.
17. Lower layer LP_QoSViolationInd's receiving incurs upper layer L2CA_QoSViolationInd message, if the traffic is guanarteed, the channel is terminated by sending L2CAP_DisconnectReq, the state should be W4_L2CAP_DISCONNECT_RSP. This is missing in Table 3.1.
18. Under the OPEN state, one side sends a L2CA_ConfigReq message, and another side sends a L2CA_DisconnectReq message at the same time, so we may get the L2CAP_ConfigReq message in W4_L2CAP_DISCONNECT_RSP state.
19. When the RTX timer expires, for a connection request or configuration, if the expiration times do not reach the maximum acceptable times, L2CAP should resend the request with no change in state. For a disconnection request, if the RTX timer expires, L2CAP returns LCID to free pool and the state is changed into CLOSED. That is different from Table 3.1.
20. When the ERTX timer expires, a duplicate request is sent and a new RTX is started, so the ERTX timer is based on RTX timer. There is no final expiration for the ERTX timer. That is different from Table 3.1.
21. In a real implementation, there is a procedure to separate the packet into several packets according to the maximum acceptable MTU of the receiver, in our SDL program, default value 2 is used.
22. In a real implementation, normally it is not possible for L2CAP to get the L2CAP_CmdReject for a second time for MTU exceeded reason, L2CAP uses the C flag to mark this for receiving L2CAP_ConfigReq message.
23. During the CONFIG state, if L2CAP gets an L2CAP_CmdReject message for MTU exceeded reason, L2CAP_ConfigReq packet is separated into several packets, at least two, each has its own RTX timer.
24. Question:While in the CLOSED state, if L2CAP receives an L2CAP_DisconnectReq message and continuously sends back an L2CAP_CmdReject message for invalid CID reason, does L2CAP need to avoid this? That is, does L2CAP need to avoid the same reject reason, even for invalid CID?
25. Question:Because L2CAP allows both devices to initiate the configuration request, is it necessary for L2CAP only to allow the same service level for both devices (or both directions), best effort or guaranteed?

For inquiries regarding this project, contact David Cypher