Hi all!
Some of you will have alrady noticed, over the last few days I reviewed,
cleaned up, submitted and merged the virtual Um interface support on
both the phone side (OsmocomBB) as well as on the BTS side (OsmoBTS).
Thanks to Sebastian Stumpf for working out most of the related code,
after my initial attempt on this got stalled more than 1.5 years ago.
This means that you can now run a complete circuit-switched GSM network
without posession of any real hardware or use of any radio waves. While
that takes away almost all the fun for some of us (I would typically
agree), it opens up possibilities, particularly in terms of testing.
If anyone wants to play with it, it's actually very easy:
* build osmo-bts and the rest of the network-side code (I don't think
osmo-bts-virtual is part of the nightly Osmocom packages yet, sorry)
* run osmo-bts-virtual with a config file (example included in osmo-bts.git)
* make sure you have matching unit_id, band, ... between BTS and
BSC/NITB, just like with real hardware
OsmoBTS will start to send downlink BCCH / CCCH frames to a multicast
IPv4 address (default: 239.193.23.1) to the usual GSMTAP port 4729. If
you don't have any specific multicast routing set up, this will be
visible with TTL=1 on the network device of your default route. You
should see the GSMTAP frames in wireshark.
On the OsmocomBB side, simply start the virt_phy binary. It replaces
your calypso based phoen and its firmware and offers the L1CTL socket to
the "layer23" programs like "mobile". Once virt_phy is running, you can
start "mobile" just like with real hardware. The phone will scan the
multicast frames for BCCH messages, build up a list of currently
received BTSs and then perform normal cell selection followed by
location update.
Everything from this point on is just normal. You cannot make voice
calls, but any signaling related transactions (LU, SMS, USSD, even call
signalling) should work. Voice is missing as there is no format
specified on how to transmit FR/EFR/HR/AMR frames over GSMTAP yet.
If somebody plays with this, I would really appreciate if they could
update the Osmocom wiki with a guide/howto on how to use such a setup.
My personal plans are to use this for verification/testing of those bits
that are difficult in a true end-to-end setup like osmo-gsm-tester.
That includes:
* simulation of massive amount of phones, more than one can easily set
up in a lab and connect to USB + RF cabling.
* verification of SYSTEM INFORMATION messages, particularly in response
to different config files, ensuring that all related bits are set
correctly at all times, even after making dynamic updates
* verification of the PAGING code, i.e. that paging load is correctly
reported, paging messages are structured correctly, ...
* exhausting all channels using simulated phones, verification of
IMM.ASS.REJECT being sent ins such cases
* verification of TA loop
* verification of uplink power control loop
* verification of radio link timeout
* testing of emergency calls, which is very critical with real phones as
there's always some possible leakage into real networks
* verification of correct CBCH messages
* verification of LAPDm contention resolution (two phones selecting same
RACH value and going both on same dedicated channel)
* verification of measurement reporting (Um vs. RSL)
* verification of downlink RF power ramping
This will of course take some time, but I'm already making good progress
implementing some SYSTEM INFORMATION test code.
In case somebody wants to join in on any of the above topics (or has
even more ideas on what kind of tests he would want to implement), feel
free to follow up so we can coordinate.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hi,
Which USB-TTL converter do you use?
What is the output of PuTTY and mincom? Post it here.
Try using -m c123 instead of -m c123xor
KR,
Anton
2017-06-05 8:30 GMT+03:00 baymax Robo <baymax254(a)gmail.com>:
> HI again,
>
> I replaced my ttl converter, now my phone is able to communicate via
> serial port but osmocon is unable to write hello world binary. The output
> of following command is given
>
> $ ./osmocon -p /dev/ttyUSB0 -m c123xor ../../target/firmware/board/
> compal_e88/hello_world.compalram.bin
>
>
> output:
>
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: f7 .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: 72 r
> got 3 bytes from modem, data looks like: 82 bf 7d ..}
> got 1 bytes from modem, data looks like: fd .
> got 1 bytes from modem, data looks like: 7f .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: a6 .
> got 1 bytes from modem, data looks like: 51 Q
> got 1 bytes from modem, data looks like: d2 .
> got 1 bytes from modem, data looks like: 51 Q
> got 1 bytes from modem, data looks like: 0a .
> got 1 bytes from modem, data looks like: 3a :
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: 4d M
> got 1 bytes from modem, data looks like: a3 .
> got 1 bytes from modem, data looks like: a3 .
> got 1 bytes from modem, data looks like: da .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: f7 .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: 72 r
> got 1 bytes from modem, data looks like: 82 .
> got 1 bytes from modem, data looks like: bf .
> got 1 bytes from modem, data looks like: 7d }
> got 1 bytes from modem, data looks like: fd .
> got 1 bytes from modem, data looks like: 7f .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: a6 .
> got 1 bytes from modem, data looks like: 51 Q
> got 1 bytes from modem, data looks like: d2 .
> got 1 bytes from modem, data looks like: 51 Q
> got 1 bytes from modem, data looks like: 0a .
> got 1 bytes from modem, data looks like: 3a :
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: 4d M
> got 1 bytes from modem, data looks like: a3 .
> got 1 bytes from modem, data looks like: a3 .
> got 1 bytes from modem, data looks like: da .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: fb .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: 72 r
> got 1 bytes from modem, data looks like: 82 .
> got 1 bytes from modem, data looks like: bf .
> got 1 bytes from modem, data looks like: 7d }
> got 1 bytes from modem, data looks like: fd .
> got 1 bytes from modem, data looks like: 7f .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: a6 .
> got 1 bytes from modem, data looks like: 51 Q
> got 1 bytes from modem, data looks like: d2 .
> got 1 bytes from modem, data looks like: 51 Q
> got 1 bytes from modem, data looks like: 0a .
> got 1 bytes from modem, data looks like: 3a :
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: 4d M
> got 1 bytes from modem, data looks like: a3 .
> got 1 bytes from modem, data looks like: a3 .
> got 1 bytes from modem, data looks like: da .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: fb .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: 72 r
> got 1 bytes from modem, data looks like: 82 .
> got 1 bytes from modem, data looks like: bf .
> got 1 bytes from modem, data looks like: 7d }
> got 1 bytes from modem, data looks like: fd .
> got 1 bytes from modem, data looks like: 7f .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: a6 .
> got 1 bytes from modem, data looks like: 51 Q
> got 1 bytes from modem, data looks like: d2 .
> got 1 bytes from modem, data looks like: 51 Q
> got 1 bytes from modem, data looks like: 0a .
> got 1 bytes from modem, data looks like: 3a :
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: 4d M
> got 1 bytes from modem, data looks like: a3 .
> got 1 bytes from modem, data looks like: a3 .
> got 1 bytes from modem, data looks like: da .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: f7 .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: 72 r
> got 1 bytes from modem, data looks like: 82 .
> got 1 bytes from modem, data looks like: bf .
> got 1 bytes from modem, data looks like: 7d }
> got 1 bytes from modem, data looks like: fd .
> got 1 bytes from modem, data looks like: 7f .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: a6 .
> got 1 bytes from modem, data looks like: 51 Q
> got 1 bytes from modem, data looks like: d2 .
> got 1 bytes from modem, data looks like: 51 Q
> got 1 bytes from modem, data looks like: 0a .
> got 1 bytes from modem, data looks like: 3a :
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: 4d M
> got 1 bytes from modem, data looks like: a3 .
> got 1 bytes from modem, data looks like: a3 .
> got 1 bytes from modem, data looks like: da .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: ff .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: f7 .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: 72 r
> got 1 bytes from modem, data looks like: 82 .
> got 1 bytes from modem, data looks like: bf .
> got 1 bytes from modem, data looks like: 7d }
> got 1 bytes from modem, data looks like: fd .
> got 1 bytes from modem, data looks like: 7f .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: a6 .
> got 1 bytes from modem, data looks like: 51 Q
> got 1 bytes from modem, data looks like: d2 .
> got 1 bytes from modem, data looks like: 51 Q
> got 1 bytes from modem, data looks like: 0a .
> got 1 bytes from modem, data looks like: 3a :
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: 4d M
> got 1 bytes from modem, data looks like: a3 .
> got 1 bytes from modem, data looks like: a3 .
> got 1 bytes from modem, data looks like: da .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: f7 .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: 72 r
> got 1 bytes from modem, data looks like: 82 .
> got 1 bytes from modem, data looks like: bf .
> got 1 bytes from modem, data looks like: 7d }
> got 1 bytes from modem, data looks like: fd .
> got 1 bytes from modem, data looks like: 7f .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: a6 .
> got 1 bytes from modem, data looks like: 51 Q
> got 1 bytes from modem, data looks like: d2 .
> got 1 bytes from modem, data looks like: 51 Q
> got 1 bytes from modem, data looks like: 0a .
> got 1 bytes from modem, data looks like: 3a :
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: 4d M
> got 1 bytes from modem, data looks like: a3 .
> got 1 bytes from modem, data looks like: a3 .
> got 1 bytes from modem, data looks like: da .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: fb .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: 72 r
> got 1 bytes from modem, data looks like: 82 .
> got 1 bytes from modem, data looks like: bf .
> got 1 bytes from modem, data looks like: 7d }
> got 1 bytes from modem, data looks like: fd .
> got 1 bytes from modem, data looks like: 7f .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: a6 .
> got 1 bytes from modem, data looks like: 51 Q
> got 1 bytes from modem, data looks like: d2 .
> got 1 bytes from modem, data looks like: 51 Q
> got 1 bytes from modem, data looks like: 0a .
> got 1 bytes from modem, data looks like: 3a :
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: 4d M
> got 1 bytes from modem, data looks like: a3 .
> got 1 bytes from modem, data looks like: a3 .
> got 1 bytes from modem, data looks like: da .
> got 1 bytes from modem, data looks like: 00 .
> got 1 bytes from modem, data looks like: 00 .
>
>
> and output on putty is unreadable. Kindly guide me what's wrong and how
> can it be fixed.
> Thanks
>
> On Thu, Jun 1, 2017 at 12:39 PM, Anton Gorbachev <antgorka(a)gmail.com>
> wrote:
>
>> If you cannot get @ftmtoolerror with minicom then your jack is NOT
>> working or your TTL converter is broken (was burnt during soldering?:)
>>
>> If you have another OS (e.g. Windows machine) you can put the device in
>> the PC, find out which serial line it is using,
>> run PuTTY, set Destination to Serial, COM9 (or what you find out),
>> speed 115200, connect.
>> Then push the power button on motorola, you must see @ftmtoolerror there.
>> If not, try another jack, another TTL converter, remove phone plastic case
>> as I told already..
>>
>> No more ideas :)
>>
>> KR,
>> Anton
>>
>>
>> 2017-06-01 10:27 GMT+03:00 baymax Robo <baymax254(a)gmail.com>:
>>
>>> Oh okay. The headphone jack is working fine, i have tested it. And
>>> helloworld isn't working. Can you tell some other method to test phones
>>> connectivity with my system.
>>>
>>> On Thu, Jun 1, 2017 at 12:16 PM, Anton Gorbachev <antgorka(a)gmail.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> Check the picture
>>>> https://osmocom.org/attachments/download/2091/motorola_c123_
>>>> hello_world.jpg
>>>>
>>>> I mean the outer plastic case of the phone may not allow your jack to
>>>> be inserted at the whole length to thoe whole even if it looks like OK.
>>>> It depends on your jack case shape.
>>>>
>>>> KR,
>>>> Anton
>>>>
>>>> 2017-06-01 9:57 GMT+03:00 baymax Robo <baymax254(a)gmail.com>:
>>>>
>>>>> Hi,
>>>>>
>>>>> Thanks for replying back.
>>>>>
>>>>> I am not using virtualized environment. No success with minicom test.
>>>>> What exactly do you mean by jack is being plugged on the whole length, i
>>>>> didn't get it.
>>>>>
>>>>>
>>>>> On Thu, Jun 1, 2017 at 11:16 AM, Anton Gorbachev <antgorka(a)gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Are you sure the jack is being plugged on the whole length?
>>>>>> Did you get success with minicom test?
>>>>>> I would recommend you to disassemble phone and check whether the jack
>>>>>> plugged an the whole length.
>>>>>> Do you use virtualized OS or normal? If virtualized, try to play with
>>>>>> the settings.
>>>>>>
>>>>>> KR,
>>>>>> Anton
>>>>>>
>>>>>> 2017-06-01 7:30 GMT+03:00 baymax Robo <baymax254(a)gmail.com>:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I am trying to write osmocombb to Motorolla c118 phone by following
>>>>>>> the given [1] guide.I have successfully compiled firmware binaries but
>>>>>>> having issues while writing them to phone.
>>>>>>>
>>>>>>> I connected motorolla c118 via USB Serial To RS232 TTL to 2.5mm
>>>>>>> audio jack, using the given guide [2]
>>>>>>>
>>>>>>> When I run this command
>>>>>>>
>>>>>>> $ dmesg | grep tty
>>>>>>>
>>>>>>> I get the following output
>>>>>>>
>>>>>>> [ 0.000000] console [tty0] enabled
>>>>>>> [ 14.946936] usb 3-6: pl2303 converter now attached to ttyUSB0
>>>>>>> [ 973.747957] pl2303 ttyUSB0: pl2303 converter now disconnected
>>>>>>> from ttyUSB0
>>>>>>> [ 1484.595816] usb 3-6: pl2303 converter now attached to ttyUSB0
>>>>>>> [ 1845.344494] pl2303 ttyUSB0: pl2303 converter now disconnected
>>>>>>> from ttyUSB0
>>>>>>> [ 2643.566407] usb 3-6: pl2303 converter now attached to ttyUSB1
>>>>>>>
>>>>>>> And on running this
>>>>>>>
>>>>>>> $ sudo cu -l /dev/ttyUSB1 -s 115200
>>>>>>>
>>>>>>> I get a connected message but no further progress is done. When i
>>>>>>> press Power button briefly, no activity is shown. I have tried with two
>>>>>>> phones but no success on any. I have checked the connectivity between
>>>>>>> headphone jack and USB serial chip via voltmeter, it is fine as well. Also
>>>>>>> tried by doing Master reset on phone but no use. What can be issue and how
>>>>>>> can i fix it. ?
>>>>>>>
>>>>>>> Kindly ignore any mistakes, i am new to this domain, couldn't find
>>>>>>> much help on google as well :(
>>>>>>>
>>>>>>> [1]
>>>>>>> https://osmocom.org/projects/baseband/wiki/Software_Getting_Started
>>>>>>> https://osmocom.org/projects/baseband/wiki/Osmocon
>>>>>>>
>>>>>>> [2]
>>>>>>> http://www.linuxx.eu/2014/09/osmocombb-hardware-and-software
>>>>>>> -setup.html
>>>>>>>
>>>>>>> [2]
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Hi Maxim,
> Really cool hack - nice to see it's progressing :)
Thanks!
> Is there some wiki page or readme somewhere which can be
> used as more detailed reference? I'm sure people trying to
> replicate your setup would appreciate it.
Good idea! I'll write a brief description, how to run on SDR
and the road map of the project.
> Also, what are you plans regarding upstreaming osmocom-bb changes?
Well, there are many. Some points from my TODO list:
- Restructurize the project to have a common include directory
for both 'host' and 'target' parts. I don't like the current
problem with 'l1ctl_proto.h': we have several symlinks because
the '$(top_srcdir)/include' is out of include path.
- Extend the L1CTL protocol to have a capability to request
some information about L1 platform, e.g. TX_SUPPORT,
FHSS_SUPPORT, SIM_SUPPORT, PHY_TYPE, etc.
See http://osmocom.org/issues/1461 for details.
- Finish Harald's work, related to getting rid of outdated copy
of libosmocore inside OsmocomBB. Some things are still require
careful testing after migration to newer code.
- Since we have some good updates in Osmcoom gapk, it would be
cool to have audio playback and recording implemented in mobile
application. This way, it will be possible to speak exactly
from PC running the GSM L2 and L3 stack.
- Write a simple (the most things already implemented) tool,
aimed to provide TDMA clock indications from existing BTS.
I'll be happy to see any opinions and additions ;)
With best regards,
Vadim Yanitskiy.
Dear Osmocom community,
I would like to share some good news about development of SDR PHY
for OsmocomBB. In a few words: I was managed to make xCCH and SCH
decoding work, so the ccch_scan application works now!
As already pointed out, I use GNURadio and GR-GSM as a back-end
for signal processing (burst detection and demodulation). Despite
GR-GSM provides some blocks for decoding bursts into L2 packets,
there are some reasons why I don't use them:
- First of all, I would like to keep OsmocomBB compatible with
OsmoTRX, which can only work with raw GSM bursts. Moreover,
one already has TX capability and better stability.
- GR-GSM is only capable to decode xCCH and TCH/F. Other logical
channels (like TCH/H and PDTCH) aren't supported yet.
- GR-GSM uses decoding implementation from OpenBTS project, which
has lower performance / code quality than implementation from
libosmocoding. BTW: Piotr Krysik was working on this issue, and
some work, related to libosmocoding migration, already done, but
not finished for now.
So, we have a simple GR-GSM follow graph, which sends GSM bursts and
some corresponding info (RSSI, frame number, timeslot index) to the
application I am currently working on - trxcon. I have migrated and
a bit modified TDMA scheduler from OsmoBTS project. At the moment,
the application is capable to collect xCCH and SCH bursts, decode
them and send to higher layer applications (L2 & L3) via L1CTL link.
Regarding to L1CTL protocol, trxcon handles the following requests:
- L1CTL_RESET_REQ
- L1CTL_FBSB_REQ
- L1CTL_CCCH_MODE_REQ
- L1CTL_ECHO_REQ
All the results of my work may be found here:
https://github.com/axilirator/gr-gsm/tree/fixeria/trxhttp://git.osmocom.org/osmocom-bb/log/?h=fixeria/sdr_phy
If someone would like to test, one will need:
- GNURadio framework
- gr-osmosdr
- Custom GR-GSM with 'TRX Interface' block (link above)
- fixeria/sdr_phy branch of OsmocomBB (link above)
- SDR device supported by gr-osmosdr
Regarding to the latest requirement, UmTRX board requires external
power source / active cooling, and takes some space on my table, so
I use RTL-SDR. Sounds crazy, but OsmocomBB works on RTL-SDR ;)
One could be used until TX capabilities are implemented.
With best regards,
Vadim Yanitskiy.
Hello FreeCalypso and Osmocom communities,
I am in the process of creating an informal organisation representing
the interests of those members of the GSM universe whose interests are
not represented by GSMA etc, and I am inviting you to join me in this
venture. I propose that we name our informal organisation GSMUA,
standing for GSM Users Association, and my vision for this GSMUA is to
be a counter-body (antibody?) to the official GSMA. I just registered
the gsmua.org domain name, but there is no website or mailing list set
up yet. If someone from the Osmocom camp would like to host the
server infrastructure for gsmua.org, I will happily point the DNS to
you, otherwise the FreeCalypso family can host it on our server.
My vision for GSMUA is to represent the interests of GSM end users
(empowered end users who wish to fully own and control all aspects of
their user equipment while operating on public mobile networks in a
fully spec-compliant manner), small boutique manufacturers of GSM
devices (both MS/user equipment and network infrastructure), small
community network operators and others whose interests are not
represented by GSMA etc, especially in cases where our interests are
in direct conflict with the interests of big players such as giant
device manufacturers, giant commercial network operators and
governments.
A key goal of GSMUA is to be project-neutral, that is, every person
and every small company belonging to any of the categories listed
above (empowered end user, small boutique device manufacturer, small
community network operator etc) should be fully welcome regardless of
which specific project they are associated with. As of today there
are at least two different projects offering GSM MS implementations
(OsmocomBB and FreeCalypso) and at least two different projects
offering network-side GSM implementations (Osmocom and OpenBTS), and I
hope that this number of available alternatives will continue to grow:
freedom of choice is always a good thing. But at the present time
there exists no neutral soil on which members of different projects
with a common interest (GSM networks and devices serving the interests
of end users rather than big corporations and governments) and a
common enemy (just named) can meet, and this lack of neutral meeting
ground is the problem which GSMUA is meant to solve.
I also have one practical application for GSMUA in mind already: to
manage and legitimize recycling of wasted IMEI number ranges. By the
official rules of GSMA etc each different *type* of GSM mobile
equipment requires a different TAC, i.e., a range of at least 1 million
IMEI numbers. So if a small boutique GSM device manufacturer makes a
boutique MS device of which no more than 100 units will ever be made,
999900 IMEI numbers have to be wasted by the official rules. While I
don't know of any manufacturer who got a range of 1 million IMEIs and
only made 100 devices, we do have examples like Openmoko GTA01/02 and
Pirelli DP-L10. In the case of Openmoko GTA02 I've been told that
about 15 thousand units were made in total; in the case of Pirelli
DP-L10 it appears that the total number produced was somewhere under
100 thousand. In each case a full range of 1 million IMEIs was
allocated, and at least 900 thousand numbers out of each range are
currently unused and wasted.
If a small boutique manufacturer wishes to offer a boutique GSM MS
product to the general public and wishes to ship each unit with a
world-unique IMEI that stands a good chance of being accepted as valid
by common GSM networks, and the product in question does not qualify
for IMEI allocation by the official rules (e.g., the product is a
development board specifically intended for users to run their own
firmware and connect to live public networks with it, taking full
personal responsibility for their actions) - the situation I found
myself in with my GSM MS development board - I feel that the small
boutique manuf in question should be empowered to squat on a small
subrange of someone else's IMEI range if it is known beyond reasonable
doubt to be wasted and unused.
However, this recycling of wasted IMEI number ranges could be better
organized and given at least some aura of semi-legitimacy if there
were a community body set up to manage it, and this is where my
proposed GSMUA can come in. Once we get our GSMUA up and running and
assign a group of volunteers to be IMEI recycling managers, any small
GSM or 3G+ device manufacturer who needs a small range of IMEI numbers
will be able to request one from GSMUA, and we will allocate and
assign these small subranges out of whatever wasted range we decide to
squat on, ensuring that each requestor gets a different subrange.
So these are my ideas, and I would like to see them turn into reality.
We are going to need a simple website and a community mailing list at
gsmua.org, and for the IMEI recycling service we will need a small
group of volunteers to serve as its managers - I and Das Signal from
FreeCalypso will be happy to serve on that panel, but it would be nice
to also have someone from the Osmocom camp for better neutrality.
Bright Blessings,
Mychaela Falconia,
Mother of FreeCalypso
