В Bluetooth мастер инициирует связь с подчиненным. На уровне основной полосы мастер опрашивает раба. Однако на уровне приложения (API) это абстрагируется, что позволяет как ведущему устройству отправлять ведомому, так и ведомому отправлять ведущему.
Ситуация, которую вы описываете, является scatternet. Спецификация Bluetooth позволяет использовать scatternet. Используемый вами стек Bluetooth может накладывать ограничения на то, разрешен ли scatternet и, в более общем плане, какие конфигурации главного / подчиненного устройства разрешены (например, разрешено число одновременных ведомых устройств).
Вы обнаружите, что при взаимодействии с некоторыми устройствами требуется переключение ролей, чтобы предотвратить использование сетей. Например, удаленное устройство (ведущее устройство) может инициировать соединение с сотовым телефоном (ведомое устройство); Как только соединение установлено, сотовый телефон запрашивает смену роли, становясь ведущим. Это позволяет телефону оставаться мастером во всех соединениях и предотвращает формирование scatternets. В зависимости от API этот переключатель ролей может быть полностью прозрачным для вашего приложения. Вы не узнаете, что это произошло без следа от анализатора протоколов. Вы заметите снижение производительности, так как ведомый не может передавать так часто, как ведущий (так как ведомый не "управляет" соединением).
JSR-82 сам по себе не позволяет запрашивать смену роли. Если вы посмотрите на ServiceRecord.getConnectionURL(int, boolean), вы увидите, что вы можете требовать, чтобы ваше устройство было ведущим (передавая true), или вы можете разрешить ведущий или подчиненный режим (передавая false).
Спецификация Bluetooth (доступна здесь ) - хорошее место, чтобы начать понимать, как работают пикосети и скатернеты. Вам следует обратиться к документации по JSR-82 и, если возможно, к документации по вашему стеку, чтобы лучше понять некоторые из специфических для стека ограничений, которые могут присутствовать.