[Commotion-dev] Tests [Was: Re: Experiences with AR7xxx based USB wifi adapter?]

[Paul Gardner-Stephen]

Hello Stephane,

On Wed, Dec 12, 2012 at 9:03 PM,  <stephane at shimaore.net> wrote:
>> On a related note, I have been thinking for a couple of weeks now that
>> we need to start specifying what use cases we want to test against for
>> integration of the Serval and OpenBTS stuff into commotion.
>> We have been working against some informal use-cases, primarily meshed
>> BTS->BTS GSM calls and meshed BTS->serval phone calls.  But it would
>> be a good idea, I think, to try to firm up a well defined set of
>> use-cases that we should be testing against to make sure that
>> Commotion has the desired capabilities.
>
> I can't help much with the definition of test cases wrt mesh and radio,
> but I might be able to help writing voice test cases. Do you have a format
> in mind for these? (And eventually, where would they live?)
> S.

I think the test definition will need to occur at two levels:

1. A high-level use-case type approach, where we describe the topology
and expected functionality in general terms, e.g., two open-bts units
meshing with GSM calls routing between them.  These are linked to
capabilities that Commotion wishes to deliver.
2. Finer level definition where we break apart the use-cases into
specific scripted (but not necessarily automated) tests.  Some tests
may be VM based, but there would be expected to be a cap-stone test
using real hardware in the open somewhere.

As for where they should live, I think somewhere on the commotion wiki
would be appropriate.

Some use-case level tests that I think make sense are as follows. It
may be that some are outside of what we can achieve under current
contracts, but they would provide clear guidance as to where we want
to get to, as well as give us clearly defined tasks to seek funding
support for from various sources.

0. Deploy Commotion/OpenBTS/Serval image onto OpenBTS hardware
1. GSM->GSM VoMP phone call via single OpenBTS
2. GSM->GSM VoMP phone call via two meshed OpenBTS (single hop between
the OpenBTS units)
3. GSM->GSM VoMP phone call via meshed OpenBTS (multiple hops between
the OpenBTS units)
4. SMS between GSM phones via single OpenBTS
5. SMS between GSM phones via two meshed OpenBTS (single hop between
the OpenBTS units)
6. SMS between GSM phones via two meshed OpenBTS (multiple hops
between the OpenBTS units)
7. VoMP phone call between GSM phone on OpenBTS unit and Serval mesh
phone (single hop)
8. VoMP phone call between GSM phone on OpenBTS unit and Serval mesh
phone (multiple hops)
9. SMS between GSM phone and Serval mesh phone (single hop) (requires
OpenBTS/Serval SMS integration which is not yet specifically funded)
10. SMS between GSM phone and Serval mesh phone (multiple hops)
(requires OpenBTS/Serval SMS integration which is not yet specifically
funded)
11. GSM phone registered on one OpenBTS unit can roam to another
OpenBTS unit and retain its identity, and receive calls/SMS (requires
OpenBTS units to share registration information, probably via Serval
Rhizome for resilience, not yet specifically funded)
12. GSM phone can leave encrypted voice mail for other GSM phones
and/or Serval Mesh phones (stored and delivered by Serval Rhizome, not
yet specifically funded)
13. Replacing or adding new OpenBTS units results in a single unified
network (dependent on achieving test 11, not yet specifically funded)
14. VoMP calls/SMS over GPRS/EDGE on OpenBTS units for improved
end-user security (OpenBTS unit cannot decode call or message, not yet
specifically funded).

I am sure there are many more, but the above seems to me to cover most
of the functionality that would allow a "borgtel" style ad-hoc mobile
telephone network to be deployed and organically grown by its users.

Paul.