[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bluetooth-dev] three question about the specification
Here are my opinoins. If they are wrong, others please correct me.
>i have three question:
>one is about the Connection_Handle in HCI layer. My understanding is the CH is associated with one of remote devices. If my understanding is right , then why CH field is 12 bits, since there are seven active members and 255 parked members in piconet in all?
**********Connection handle also recognises the type of the link, viz
ACL/SCO. The HCI comes to know about the connection handle through the
connection_complete event and for both ACL and SCO link establishment,
you get this event. So, saying one connection handle for one remote
device may not be right! Hence theoritically, you can have more than 255
+ 7 connection handles.
>the other is about the CID(Channel Identifier) in L2CAP layer. Since the RFCOMM take the main responsibility of multiplex logic serial link above the RFCOMM layer, why the CID field in L2CAP layer requires 2 bytes? I think it too long for that.
********CID is not only for RFCOMM but applicable for all the layers
(like SDP, TCS, BNEP etc) which operate above L2CAP. Also, L2CAP
alloactes one CID per upper layer per device. So, if a device is
connected to 7 more devices at the RFCOMM level then you have seven
CIDs and not one. At the same time you can have SDP, BNEP connections
too. Also there are 40 reserved (presently three are used) CIDs for
future signalling use. As the specification evolves, there can be more
and more layers sitting above L2CAP and hence allocation of 2 bytes for CID.
>the last question is the reassemble function of the L2CAP layer. This is the HCI layer function if there is HCI layer, then , in this function , it uses the length of L2CAP_PDU and the flags field in HCI_PDU, then my question is what is the function about the L_CH field in ACL header(it has the reassemble function, but it seems that we don't use it)?
*****On page 258, the spcification tells that "L_CH distinguishes L2CAP
packets from LMP packets". In an implementation where HCI is present,
the use of L_CH at HCI/l2cap level may not be that evidant, as no
packets received by HCI will have the code '11'. Also, as you said
implementations with HCI take care of re-assembly with the PB flag of
HCI. But, think about the single chip solutions where HCI is not present.
Hope this has helped you.
>by the way, i am studying the bluetooth specification, would you please introduce me a forum discussing bluetooth specification or other similar website.
>Any help will be appreciated,thank you in advance.
>To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
>the body of a message to firstname.lastname@example.org
To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to email@example.com