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").
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.
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.
Request for Comment
-------------------
Comments, omissions and suggestions for improvement are invited.
Regards,
Tim Monahan-Mitchell | Qualcomm Innovation Center, Inc |
[email protected]
Hi Tim,
* Marcel Holtmann <[email protected]> [2010-03-04 17:41:40 -0800]:
> 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.
MaxTransmit should be in the sockopt too.
>
> > 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Gustavo F. Padovan
http://padovan.org
Hi David,
> > 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.
>
> Why HCI_80211 and not HCI_AMP? The stack shouldn't care what the AMP's
> radio actually is and with some devices (e.g., standard SDIO ones) it's
> not even possible to tell what the radio is.
we will be adding a HCI_UWB once that specification gets ratified. And
the controller type is an official piece of information inside the AMP
manager. That part needs to know which type of AMP it is. Also the
driver actually should know what type of AMP it is.
I see your point that for fully generic HCI transports they might not
know the type upfront and we need to handle that. We will cross that
bridge when we come to it. Right now we just got started.
Regards
Marcel
Hi, David,
>> 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.
>
> Why HCI_80211 and not HCI_AMP? The stack shouldn't care what the AMP's
> radio actually is and with some devices (e.g., standard SDIO ones) it's
> not even possible to tell what the radio is.
One answer is, the "Read Local AMP Info Command" requires the Controller
Type. The value appears in some other AMP HCI commands as well.
Regards,
Tim
Marcel Holtmann wrote:
>
> 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.
Why HCI_80211 and not HCI_AMP? The stack shouldn't care what the AMP's
radio actually is and with some devices (e.g., standard SDIO ones) it's
not even possible to tell what the radio is.
David
--
David Vrabel, Senior Software Engineer, Drivers
CSR, Churchill House, Cambridge Business Park, Tel: +44 (0)1223 692562
Cowley Road, Cambridge, CB4 0WZ http://www.csr.com/
Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
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.
> >> 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
Marcel
Thanks, Marcel,
> 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.
>
>> 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?
>
>> 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.
>
> Regards
>
> Marcel
Hi,
On Fri, Mar 5, 2010 at 3:41 AM, Marcel Holtmann <[email protected]> wrote=
:
> Hi Tim,
>
>> QuIC (Qualcomm Innovation Center, Inc., a member of the Code Aurora Foru=
m)
>> is planning an implementation of AMP for BlueZ. =A0Here are some details=
of
>> our technical approach. =A0We 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 T=
CP
>>
>> - 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. =A0The extensions we foresee are sockopt configura=
tion
>> of MPS (max PDU size), TX window size (currently hard coded), and a simp=
le
>> 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. =A0One is to suppo=
rt
>> L2CAP lockstep configuration, in addition to the present standard
>> configuration process. =A0Another addition is support for the extended T=
X
>> 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 a=
nd
>> 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. =A0L2CAP 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 a=
nd
>> logical links on an AMP controller. =A0Additionally 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. A=
MP
>> 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.
I have to agree with Marcel on this, we probably don't really need any
AMP adapter exposed in BlueZ, perhaps we can have a property in the
adapter saying if the adapter has AMP capability or not, but even
that I guess is too soon to evaluate so lets first concentrate in
kernel only leaving DBus for latter.
--=20
Luiz Augusto von Dentz
Computer Engineer
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
Hi, David.
> David Vrabel wrote:
>> Tim Monahan-Mitchell wrote:
>>>
>>> If the HCI_80211 symbol in hci.h is changed instead to HCI_AMP, where
>>> should the 0x01 value for '802.11 AMP Controller' (listed in
>>> Bluetooth.org's Assigned Number listing for Controller_Type) go?e
>>
>> I don't think it needs to go anywhere, the actual values aren't
>> important from the point of view of the AMP manager.
>
> I may have misunderstood your question. There will need to be an
> additional "controller_type" field which will get filled in when the
> local amp info is read from the controller.
>
> There will also need to be a table somewhere mapping controller types to
> dedicated amp link key length and KeyID. The will be filled in from the
> assigned numbers and will be a very short table one 1 entry for now.
>
> I do not think we need #define for the various AMP controller types.
I would think such a set of #defines are needed, so that everyone is on
the same page?
Put another way, if one device has an AMP of type 802.11, and a remote has
an AMP of type HCI_UWB, it would seem the AMP Manager needs to know not to
try to converse via AMP with that peer, no?
Also have a look at the Core Spec, under 'READ LOCAL AMP INFO COMMAND'.
The 'Controller_Type' list (of which there is only 802.11 now) will
grow...
Controller Type appears elsewhere in the A2MP protocol...
Sorry if I'm not following you completely.
--
Regards,
Tim Monahan-Mitchell
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
David Vrabel wrote:
> Tim Monahan-Mitchell wrote:
>>
>> If the HCI_80211 symbol in hci.h is changed instead to HCI_AMP, where
>> should the 0x01 value for '802.11 AMP Controller' (listed in
>> Bluetooth.org's Assigned Number listing for Controller_Type) go?e
>
> I don't think it needs to go anywhere, the actual values aren't
> important from the point of view of the AMP manager.
I may have misunderstood your question. There will need to be an
additional "controller_type" field which will get filled in when the
local amp info is read from the controller.
There will also need to be a table somewhere mapping controller types to
dedicated amp link key length and KeyID. The will be filled in from the
assigned numbers and will be a very short table one 1 entry for now.
I do not think we need #define for the various AMP controller types.
David
--
David Vrabel, Senior Software Engineer, Drivers
CSR, Churchill House, Cambridge Business Park, Tel: +44 (0)1223 692562
Cowley Road, Cambridge, CB4 0WZ http://www.csr.com/
Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
Tim Monahan-Mitchell wrote:
>
> If the HCI_80211 symbol in hci.h is changed instead to HCI_AMP, where
> should the 0x01 value for '802.11 AMP Controller' (listed in
> Bluetooth.org's Assigned Number listing for Controller_Type) go?e
I don't think it needs to go anywhere, the actual values aren't
important from the point of view of the AMP manager.
David
--
David Vrabel, Senior Software Engineer, Drivers
CSR, Churchill House, Cambridge Business Park, Tel: +44 (0)1223 692562
Cowley Road, Cambridge, CB4 0WZ http://www.csr.com/
Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
Hi David and Marcel,
I added on to this thread in regards to today's patch of "Bluetooth: HCI
devices are either BR/EDR or AMP radios" (09-Aug-2010).
>> > 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.
>>
>> Why HCI_80211 and not HCI_AMP? The stack shouldn't care what the AMP's
>> radio actually is and with some devices (e.g., standard SDIO ones) it's
>> not even possible to tell what the radio is.
>
> we will be adding a HCI_UWB once that specification gets ratified. And
> the controller type is an official piece of information inside the AMP
> manager. That part needs to know which type of AMP it is. Also the
> driver actually should know what type of AMP it is.
>
> I see your point that for fully generic HCI transports they might not
> know the type upfront and we need to handle that. We will cross that
> bridge when we come to it. Right now we just got started.
>
> Regards
>
> Marcel
If the HCI_80211 symbol in hci.h is changed instead to HCI_AMP, where
should the 0x01 value for '802.11 AMP Controller' (listed in
Bluetooth.org's Assigned Number listing for Controller_Type) go?
Thanks,
Tim Monahan-Mitchell
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.