Hi Marcel,
>> >> QuIC (Qualcomm Innovation Center, Inc., a member of the Code Aurora
>> >> Forum)
>> >> is planning an implementation of AMP for BlueZ. Here are some
>> details
>> >> of
>> >> our technical approach. We are interested in comments from the BlueZ
>> >> development community on validity and whether there are areas we have
>> >> missed.
>> >>
>> >> Features:
>> >> - Completion of L2CAP with ERTM
>> >>
>> >> - Addition of L2CAP Channel Management and AMP Manager
>> >>
>> >> - DBUS support to access AMP features, control AMP settings, etc.
>> >>
>> >> - Updates to Test Programs (hcidump, hciemu, l2test, ...)
>> >>
>> >> - Creation of a Fake PAL to facilitate desktop development using
>> wired
>> >> TCP
>> >>
>> >> - Legacy L2CAP sockets take advantage of AMP, if so enabled using new
>> >> controls (sockopts or DBUS)
>> >>
>> >> - Key Management extended for AMP Controller Keys
>> >>
>> >>
>> >> L2CAP and ERTM
>> >> --------------
>> >>
>> >> A prerequisite for AMP support is a fully functional L2CAP ERTM
>> >> implementation, including optional L2CAP features not currently
>> included
>> >> in BlueZ.
>> >>
>> >> Our overall approach is to build on the existing ERTM code in the
>> >> bluetooth-testing tree, extending the present socket interfaces that
>> are
>> >> visible to userspace. The extensions we foresee are sockopt
>> >> configuration
>> >> of MPS (max PDU size), TX window size (currently hard coded), and a
>> >> simple
>> >> AMP control policy ("BR/EDR only", "initiate on or move to AMP", or
>> >> "initiate on or move to BR/EDR, allow incoming move").
>> >
>> > I was under the impression it is best to match the MPS with the ACL
>> MTU
>> > from the controller? So do we need really an option less. Less options
>> > are less confusing for users.
>>
>> I consulted the team. They say: Yes, it's reasonable to not allow the
>> application to override automatic MPS values. For BR/EDR controllers,
>> MPS
>> should be sized appropriately for 3-DH5 packets (1021 bytes minus
>> overhead). AMP controllers report their MTU/MPS size, which will be
>> used
>> by L2CAP on AMP channels.
>
> we are not doing this right now, but using the ACL MTU is what seems to
> be best. Also for most Bluetooth chips these days, it is 1021 bytes.
>
> And even if we wanna play with it, we either make it a module parameter
> or just a debugfs value for testing. However in the end I expect the
> default value here will be fine.
>
>> >> There are a few protocol-level enhancements required. One is to
>> support
>> >> L2CAP lockstep configuration, in addition to the present standard
>> >> configuration process. Another addition is support for the extended
>> TX
>> >> window option.
>> >>
>> >> Core ERTM functionality (without the proposed additional features) is
>> >> still a work in progress, and the main area that needs attention is
>> the
>> >> implementation of the transmitter (XMIT and WAIT_F) and receiver
>> (RECV
>> >> and
>> >> SREJ_SENT) state tables as defined in the ERTM spec.
>> >>
>> >>
>> >> L2CAP and Channel Management for AMP
>> >> ------------------------------------
>> >>
>> >> Once ERTM is working without AMP, the state machine will have to be
>> >> extended to account for the extra demands of creating channels
>> directly
>> >> on
>> >> an AMP controller and AMP channel moves. L2CAP will have to deal
>> with
>> >> two
>> >> controllers (BR/EDR and AMP) while the channel move is taking place,
>> and
>> >> correctly handle lockstep reconfiguration of the L2CAP channel when
>> the
>> >> move is completing.
>> >>
>> >> To enable AMP, L2CAP itself will need to be enhanced to support the
>> A2MP
>> >> fixed channel and to use the AMP Manager to create/disconnect
>> physical
>> >> and
>> >> logical links on an AMP controller. Additionally L2CAP will need to
>> >> manage channels according to the new AMP control, moving them as
>> >> appropriate and handling remote move requests.
>> >>
>> >> The AMP Manager function will need to be created. It will support
>> >> signaling on the A2MP channel and the create/disconnect of AMP
>> physical
>> >> and logical links.
>> >>
>> >> HCI will need to be extended to support data-block-based flow
>> control.
>> >> AMP
>> >> Controllers will be presented to BlueZ as HCI devices of a new type.
>> >
>> > The block-based flow control is a missing piece, but the AMP type
>> > extension has been merged upstream. We can create HCI_BREDR and
>> > HCI_80211 controllers now. The AMP controllers are for now forced to
>> be
>> > raw devices, but that can be changed easily once we have the
>> controller
>> > init for AMP up and ready.
>>
>> I saw that patch, thanks. Any thoughts on how HCI_80211 controllers are
>> associated to the parent HCI_BREDR? Maybe they simply have the same BT
>> Addr?
>
> I don't think that the AMP controller and BR/EDR controller can have the
> same BD_ADDR. That would make no sense since they are actually two
> different entities. Also we don't need to assign parent relationship
> here at all. We have AMP discovery and every BR/EDR controller can
> potentially use any AMP controller in the whole system. There is no
> requirement to tie it to an BR/EDR controller. Just once an AMP
> controller is in use we can mark it as busy. Other than that they are
> two independent controllers.
Well, the BT Spec says that the HCI_Read_BD_ADDR command only applies to
the BR/EDR, so I agree that an AMP controller can't even have a BD_ADDR.
If the association between BR/EDR and a local AMP is temporary, perhaps
only for the duration of an AMP connection, I could see that local AMP
controllers in general could be thought of as a generic resource.
However, I am thinking of the use case where the Linux box is being used
for development, and there are two instances of BR/EDR plus AMP
controller, and they are talking to each other. Maybe they are both real
hardware of different manufacture, maybe part of the system is fake PAL,
hci emu, etc. If a BR/EDR is simply allowed to find any available local
AMP controller and grab it for temporary use, are there cases where the
BR/EDR under test grabs the wrong intended local AMP? Further, considering
that each AMP can be doing things with or without an infrastructure
connection, the test case being set up may not play out correctly?
So this is why I am thinking of there being some sort of association to be
set up between a given BR/EDR and 0 or more local AMPs, which would
simulate what's happening an actual target device.
>
>> >> DBUS Additions (bluetoothd)
>> >> ---------------------------
>> >>
>> >> org.bluez.Adapter : A new property is added, containing a list of the
>> >> associated org.bluez.AmpAdapter objects ("/org/bluez/amp{0, 1, 2,
>> >> ...}").
>> >> Associating a given AmpAdapter to a parent BR/EDR device
>> >> ("/org/bluez/hci{n}") is one method of org.bluez.AmpAdapter .
>> AmpAdapter
>> >> has other methods to obtain the local controller's type and status,
>> and
>> >> the number of physical links it carries, and to mark whether it is
>> >> available for use by the Amp Manager.
>> >>
>> >> org.bluez.Device : A new method begins the AMP Discovery procedure
>> for
>> >> that Device; an alternative would be to add the procedure to what
>> >> DiscoverServices() does. A new property contains the cached remote
>> AMP
>> >> Device list.
>> >
>> > I have to reject this. I don't seen any need to expose this. We could
>> > just do this all internally inside the kernel. The AMP policy should
>> > trigger these automatically and if AMP usage is allowed, we just pick
>> > the right AMP. Involving the user in AMP discovery makes no sense and
>> > complicates the user cases.
>>
>> Agreed, AMP Discovery will also be automatic. The thought here was to
>> allow a minimal UI to see what's happening and give some control, if
>> even
>> just for test purposes. So no dbus changes for now.
>
> We can use debugfs for this and export the AMP discovery information
> like this. Similar to inquiry cache, L2CAP channel list etc.
>
Regards & Thanks,
Tim
Hi Tim,
> >> >> QuIC (Qualcomm Innovation Center, Inc., a member of the Code Aurora
> >> >> Forum)
> >> >> is planning an implementation of AMP for BlueZ. Here are some
> >> details
> >> >> of
> >> >> our technical approach. We are interested in comments from the BlueZ
> >> >> development community on validity and whether there are areas we have
> >> >> missed.
> >> >>
> >> >> Features:
> >> >> - Completion of L2CAP with ERTM
> >> >>
> >> >> - Addition of L2CAP Channel Management and AMP Manager
> >> >>
> >> >> - DBUS support to access AMP features, control AMP settings, etc.
> >> >>
> >> >> - Updates to Test Programs (hcidump, hciemu, l2test, ...)
> >> >>
> >> >> - Creation of a Fake PAL to facilitate desktop development using
> >> wired
> >> >> TCP
> >> >>
> >> >> - Legacy L2CAP sockets take advantage of AMP, if so enabled using new
> >> >> controls (sockopts or DBUS)
> >> >>
> >> >> - Key Management extended for AMP Controller Keys
> >> >>
> >> >>
> >> >> L2CAP and ERTM
> >> >> --------------
> >> >>
> >> >> A prerequisite for AMP support is a fully functional L2CAP ERTM
> >> >> implementation, including optional L2CAP features not currently
> >> included
> >> >> in BlueZ.
> >> >>
> >> >> Our overall approach is to build on the existing ERTM code in the
> >> >> bluetooth-testing tree, extending the present socket interfaces that
> >> are
> >> >> visible to userspace. The extensions we foresee are sockopt
> >> >> configuration
> >> >> of MPS (max PDU size), TX window size (currently hard coded), and a
> >> >> simple
> >> >> AMP control policy ("BR/EDR only", "initiate on or move to AMP", or
> >> >> "initiate on or move to BR/EDR, allow incoming move").
> >> >
> >> > I was under the impression it is best to match the MPS with the ACL
> >> MTU
> >> > from the controller? So do we need really an option less. Less options
> >> > are less confusing for users.
> >>
> >> I consulted the team. They say: Yes, it's reasonable to not allow the
> >> application to override automatic MPS values. For BR/EDR controllers,
> >> MPS
> >> should be sized appropriately for 3-DH5 packets (1021 bytes minus
> >> overhead). AMP controllers report their MTU/MPS size, which will be
> >> used
> >> by L2CAP on AMP channels.
> >
> > we are not doing this right now, but using the ACL MTU is what seems to
> > be best. Also for most Bluetooth chips these days, it is 1021 bytes.
> >
> > And even if we wanna play with it, we either make it a module parameter
> > or just a debugfs value for testing. However in the end I expect the
> > default value here will be fine.
> >
> >> >> There are a few protocol-level enhancements required. One is to
> >> support
> >> >> L2CAP lockstep configuration, in addition to the present standard
> >> >> configuration process. Another addition is support for the extended
> >> TX
> >> >> window option.
> >> >>
> >> >> Core ERTM functionality (without the proposed additional features) is
> >> >> still a work in progress, and the main area that needs attention is
> >> the
> >> >> implementation of the transmitter (XMIT and WAIT_F) and receiver
> >> (RECV
> >> >> and
> >> >> SREJ_SENT) state tables as defined in the ERTM spec.
> >> >>
> >> >>
> >> >> L2CAP and Channel Management for AMP
> >> >> ------------------------------------
> >> >>
> >> >> Once ERTM is working without AMP, the state machine will have to be
> >> >> extended to account for the extra demands of creating channels
> >> directly
> >> >> on
> >> >> an AMP controller and AMP channel moves. L2CAP will have to deal
> >> with
> >> >> two
> >> >> controllers (BR/EDR and AMP) while the channel move is taking place,
> >> and
> >> >> correctly handle lockstep reconfiguration of the L2CAP channel when
> >> the
> >> >> move is completing.
> >> >>
> >> >> To enable AMP, L2CAP itself will need to be enhanced to support the
> >> A2MP
> >> >> fixed channel and to use the AMP Manager to create/disconnect
> >> physical
> >> >> and
> >> >> logical links on an AMP controller. Additionally L2CAP will need to
> >> >> manage channels according to the new AMP control, moving them as
> >> >> appropriate and handling remote move requests.
> >> >>
> >> >> The AMP Manager function will need to be created. It will support
> >> >> signaling on the A2MP channel and the create/disconnect of AMP
> >> physical
> >> >> and logical links.
> >> >>
> >> >> HCI will need to be extended to support data-block-based flow
> >> control.
> >> >> AMP
> >> >> Controllers will be presented to BlueZ as HCI devices of a new type.
> >> >
> >> > The block-based flow control is a missing piece, but the AMP type
> >> > extension has been merged upstream. We can create HCI_BREDR and
> >> > HCI_80211 controllers now. The AMP controllers are for now forced to
> >> be
> >> > raw devices, but that can be changed easily once we have the
> >> controller
> >> > init for AMP up and ready.
> >>
> >> I saw that patch, thanks. Any thoughts on how HCI_80211 controllers are
> >> associated to the parent HCI_BREDR? Maybe they simply have the same BT
> >> Addr?
> >
> > I don't think that the AMP controller and BR/EDR controller can have the
> > same BD_ADDR. That would make no sense since they are actually two
> > different entities. Also we don't need to assign parent relationship
> > here at all. We have AMP discovery and every BR/EDR controller can
> > potentially use any AMP controller in the whole system. There is no
> > requirement to tie it to an BR/EDR controller. Just once an AMP
> > controller is in use we can mark it as busy. Other than that they are
> > two independent controllers.
>
> Well, the BT Spec says that the HCI_Read_BD_ADDR command only applies to
> the BR/EDR, so I agree that an AMP controller can't even have a BD_ADDR.
that is fine. We just have to handle AMP controllers with BDADDR_ANY
then. And since you can't really bind a L2CAP socket to a specific AMP
anyway (you always bind to a BR/EDR controller), I don't see any
problems with this.
> If the association between BR/EDR and a local AMP is temporary, perhaps
> only for the duration of an AMP connection, I could see that local AMP
> controllers in general could be thought of as a generic resource.
>
> However, I am thinking of the use case where the Linux box is being used
> for development, and there are two instances of BR/EDR plus AMP
> controller, and they are talking to each other. Maybe they are both real
> hardware of different manufacture, maybe part of the system is fake PAL,
> hci emu, etc. If a BR/EDR is simply allowed to find any available local
> AMP controller and grab it for temporary use, are there cases where the
> BR/EDR under test grabs the wrong intended local AMP? Further, considering
> that each AMP can be doing things with or without an infrastructure
> connection, the test case being set up may not play out correctly?
>
> So this is why I am thinking of there being some sort of association to be
> set up between a given BR/EDR and 0 or more local AMPs, which would
> simulate what's happening an actual target device.
In real devices, you only get one BR/EDR controller and 0..n AMP
controllers. So that is not a problem at all.
With test or development systems, we can just use special debugfs files
to force the relationship. However I don't see a big problem either here
since the AMP manager protocol is capable of deciding between 802.11 and
fake PALs. So we might have an option on the L2CAP socket to select a
controller type like 802.11, UWB, fake etc., but everything else should
really not matter and multiple BR/EDR controllers could share one or
more AMP controllers.
I really wanna keep this flexible. So if you need more AMP, you just
attach a WiFi USB dongle. If its driver allows AMP support, then you
automatically another AMP and any BR/EDR controller could use it.
Trying to express and configure relationships just makes it more
complicated for no benefit. The simple use case with one BR/EDR
controller will always work.
Regards
Marcel