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.
> 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.
> 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.
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
