RFCOMM provides serial port emulation based on L2CAP protocol.
1: Byte sequence
All binary data are arranged from low to high and read from left to right. ( Sorted by little endian )
2: RFCOMM frame structure
There is always exactly one RFCOMM frame contained in each L2CAP frame.
RFCOMM does not use the open and close flags in GSM 07.10. Use only those fields contained in the exchange flags between the L2CAP layer and the RFCOMM layer
2.1 Address field
The address field occupies one byte, including data link connection identifier (DLCI), CR, and EA.
EA means address extension, 1 means: the address field has only the current byte, and 0 means: the next byte also belongs to the address field. There is currently no address expansion.
CR (command/response) indicates: whether this frame is a command or a response.
Table 1:Command/response bit usage
| Command/response |
Direction |
C/Rvalue |
||
| Command |
Initiator |
¾¾® |
Responder |
1 |
|
|
Responder |
¾¾® |
Initiator |
0 |
| Response |
Initiator |
¾¾® |
Responder |
0 |
|
|
Responder |
¾¾® |
Initiator |
1 |
Initiator is the party that initializes the multiplexer MUX, and Responder is the party that responds to MUX initialization.
-----------------------------RFCOMM server channel allocation start---------------- --------
The server channel number of RFCOMM is a subset of the DLCI bits in the address field of GSM 70.10.
Server application registration; the channel number assigned to an RFCOMM service interface is between 1-30. [ 0 and 31 cannot be used because the corresponding DLCIs are reserved in GSM70.10, 0 and 31 correspond to the upper 5 bits of DLCI1 and DLCI63/DLCI62. The server channel occupies 5 bits, 0=00000, 31=11111, respectively for the upper 5 bits of DLCI1=000000, DLCI62=111110, and DLCI63=111111. ]
This value should be registered in the SDP database.
For an initiating device, the direction bit D=1, otherwise it is 0. When a data link is established on an existing RFCOMM session, the direction bit and the sercer channel cooperate to determine that the DLCI is connected to a specific application. This DLCI will be subsequently Data packets in both directions are shared between two endpoints. In other words, the D bit + server channel is the DLCI on GSM 70.10.
In fact, server application data for non-initiators is routed to DLCIs 2,4...60. The initiator is routed to 3, 5...61. [This can refer to the DLCI allocation of GSM 70.10].
------------------------------RFCOMM server channel allocation start--------------- ---------
------------------------------GSM 07.10 DLCI allocation start--------------- ---------
DLCI is used to mark a unique data stream and the channel between TE and MS . DLCI is dynamically allocated.
The DLCI value range is actually divided into two parts: the application on the non-initiator device uses the DLCI even number (2,4,...,60) to access, and the application on the initiator device uses the DLCI odd number (3,5,..., 61) Visit.
Note: For a device that supports multiple simultaneous RFCOMM sessions, the direction bit may not be the same in all sessions.
DLC0 : Control channel, DLCI1 , DLCI 62 , DLCI 63 are reserved.
DLCI allocation table:
Table27: DLCI Assignments
| Usage |
DLCInumber (decimal) |
Priority |
| Multiplexercontrol channel |
0 |
0 |
| ATcommands (07.07 and 07.05) |
1-7 |
7 |
| ATcommands (07.07 and 07.05) |
8-15 |
15 |
| ATcommands (07.07 and 07.05) |
16-23 |
23 |
| ATcommands (07.07 and 07.05) |
24-31 |
31 |
| ATcommands (07.07 and 07.05) |
32-39 |
39 |
| ATcommands (07.07 and 07.05) |
40-47 |
47 |
| ATcommands (07.07 and 07.05) |
48-55 |
55 |
| ATcommands (07.07 and 07.05) |
56-61 |
61 |
| Reserved |
62-63 |
|
------------------------------GSM 07.10 DLCI allocation end--------------- ---------
2.2 Control field
The control field is used to define the type of frame:
2.3 Length field
EA means extended bit, 1: only this byte is included, 0 means the next byte is included.
The length field should be included in every frame, even if the information field is an empty frame.
2.4 Information fields
The information field is the payload of the frame, which carries user information (AT commands, ppp data). The information field is only included in the UIH frame .
2.5 FCS （frame check sequence）
Calculate on different fields for different frame types.
• For SABM, DISC, UA, DM frames: on Address, Control and Length field.
• For UIH frames: on Address and Control field.
5.2 GSM multiplex opening and closing process
RFCOMM does not know the value of the close/open process defined in section 5.7 of the GSM 07.10 specification, which means that it does not support the AT command AT+CMUX and the multiplexer close command.
At any one time, there is at most one RFCOMM session between two paired devices.
When creating a new DLC, the initiator should check whether there is an RFCOMM Session with the remote device, and if so, create a new DLC on this Session. An RFCOMM session is uniquely identified by the Bluetooth addresses of two communication terminals.
5.2.1 Startup process
The device that establishes the first simulated serial port connection between the two devices is responsible for establishing the control channel of the multiplexer.
1): Use L2CAP service primitives and the opposite device to establish an L2CAP channel.
2): Send the SABM command on the DLC0 control channel to turn on the RFCOMM multiplexer, and wait for the UA response from the peer device.
After these steps, the DLCx channel for user data transmission can be established.
It is possible to establish an RFCOMM Session between two devices at the same time on an existing baseband connection. This is reflected in that the RFCOMM entity receives an L2CAP connection instruction after sending a L2CAP establishment request. In this case, the RFCOMM entity should refuse ( Responding negatively cannot determine whether the translation is correct) This received connection instruction. How to solve it depends on the specific implementation (for example: retry within a certain period of time or manually retry by the user).
5.2.2 Closing process
The device that closes the last connection (DLC) on a specific session is responsible for closing the multiplexer by closing the corresponding L2CAP channel.
Before closing L2CAP, the last connected device can send a DISC command on DLC0, and other devices respond to this DISC through UA.
5.2.3 Link loss
If the L2CAP link loss notification is received, the local RFCOMM entity sends a link loss notification to each port emulation/agent entity on the active DLC, and all resources related to this session are released.
The action of the port emulation/agent entity depends on the upper API. Assuming that the device is a DTE, for an emulated serial port, the CD, DSR and CTS signals will be cancelled.
5.4 DLCI distribution and RFCOMM server channel
Please refer to this section 2.1 Address Field
7 Interoperability with other entities
7.1 Port emulation and port proxy
Device 1 is a communication device such as a computer and printer, and device 2 is a part of the communication segment, for example: Modems
7.1.1 Port simulation entity
Port emulation entity maps system-specific communication interfaces to RFCOMM services
7.1.2 Port proxy entity
The port proxy entity forwards data from RFCOMM to the external RS-232 interface connected to the DCE device.
7.2 Search for service registration
Temporarily omitted. . .
Reference: bluetooth RFCOMM protocol
Bluetooth protocol and its source code analysis (Jin Chun, etc.)
GSM 07.10
GSM_MUX_AN_V1.00