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
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
