The XBee constructor 'rts' and 'cts' parameters determine the hardware flow control in the serial connection between the mbed processor and the XBee module.

Each of the parameters can be set to 'NC' meaning not connected or to an actual mbed module pin, leading in following 4 combinations:

• If rts pin is configured, then that pin has to be wired from the mbed module to the RTS# pin of the XBee module (pin 16 on THT modules, pin 29 on SMT modules); and the XBee module DIO6 has to be configured accordingly ("D6" at command set to 1).
  
• If cts pin is configured, then that pin has to be wired from the mbed module to the CTS# pin of the XBee module (pin 12 on THT modules, pin 25 on SMT modules); and the XBee module DIO7 has to be configured accordingly ("D7" at command set to 1).
  

CTS# line is raised by the radio to tell the cpu that it has no room to process more incoming bytes... so the cpu should stop sending data to the radio until it drops the CTS# line. If this flow control line is not used, the cpu can keep on sending data to a busy radio and the packet will be discarded or corrupted. This is quite likely to happen specially if the baudrate between cpu and radio is increased. For that reason it's recommended to wire and configure this flow control line.

RTS# line is used just for the opposite as CTS# line. It'd advise the radio to stop sending radio to the cpu... but this scenario is not likely to happen because the cpu is faster processing data than the radio generating it.