Hi,
Well thank you for your answer. I thought i could simply call my phone, the network would page it and i would have the imsi/tmsi. As i'm in a very busy cell, there are huge amounts of pagings. I have to rethink my first idea.
Stefan
----- Ursprüngliche Nachricht -----
Von: Sylvain Munaut <246tnt(a)gmail.com>
Gesendet: Donnerstag, 12. Januar 2012 18:28
An: Stefan Bauer <stefan.bauer(a)cubewerk.de>
Cc: baseband-devel(a)lists.osmocom.org
Betreff: Re: 3GPP - paging references
Hi,
> In detail how can i match the paging for my specific imsi/tmsi to the data-channel assignment?
You can't ... There is no relation between paging and the channel assignment.
When the phone sees he's being paged, he will initiate the channel
request procedure.
He sends a RACH at a given time fn with a random reference (8bits).
And then he looks for assignement matching his RACH (i.e. the time fn
and random reference are repeated back by the network in the
assignment so that a phone knows the channel was for it).
Cheers,
Sylvain
Dear developers & users,
can somebody please provide further documents to understand how paging works? In detail how can i match the paging for my specific imsi/tmsi to the data-channel assignment? I dont see my tmsi/imsi as reference in the data-channel request-frame in wireshark nor in the output of ccch_scan. I guess i have to do some math :)
Thank you.
Stefan
This is a Mailman mailing list bounce action notice:
List: baseband-devel
Member: fabian(a)auth.se
Action: Subscription disabled.
Reason: Excessive or fatal bounces.
The triggering bounce notice is attached below.
Questions? Contact the Mailman site administrator at
mailman(a)lists.osmocom.org.
Hi all!
I've mentioned this before, and I keep getting back to it: With all the
great work that has been put into OsmocomBB, we are "at an arms lengh"
away from being able to create a true Free Software mobile phone.
We already have the hardware drivers, protocol stack and even the
'mobile' program which can be used for making and receiving voice calls
and sending/receiving SMS text messages on real GSM networks!
While the journey has been a lot of fun and everyone involved has
learned a lot, we have so far been catering mstly about "scratching our
own itch", i.e. implementing what we needed in order to satisfy our ego
and/or to implement the ideas we had regarding cellular security.
I believe we cannot miss the bigger opportunity here to put our code
into bigger use: To create something like a very simple GSM feature
phone.
When we look at various areas of computing like Operating Systems or Web
browsers, Free Software is not just "the hobby project catching up" with
the vendors of proprietary software. Free Software can compete.
In the cellular area, we have still not managed to even implement the
most basic GSM feature phone that existed 15 years ago using proprietary
software. We need to work on closing that gap. We need to show that a
small community of Free Software developers can actually implement what
teams of hundreds of engineers did in a proprietary software setting 15
years ago - despite all the lack of hardware documentation or any kind
of positive feedback from the cellular chipset, handset or operator
industry.
If we don't at least get a 2G GSM cellphone implemented now, it will
probably not happen before 2G networks become insignificant in large
parts of the world.
This is a call to all hands, please support this project!
Regards,
Harald
== Technical aspects ==
I believe the first major decision is whether we focus on
1) the Openmoko FreeRunner / Neo1973 phones
Advantages:
* large screen for UI with bells and whistles
* lots of RAM and Flash, even script languages or compilation on the
device itself possible
* second processor doesn't require us to run stack + UI on once CPU
* easier debugging of UI
* various existing telephony middleware and phone dialer UI projects
of which hopefully one could be recycled
or
2) the Motorola/Compal C1xx phones
Advantags:
* many more phones available, even after our software is released
* lower cost of the individual phone
* less power consumption due to only one small ARM7 core
* smaller screen also means less fancy UI requirements
Problems:
* full stack + UI needs to run on calypso (L2/L3) and we'd probably
some kind of RTOS like NuttX instead of our 'bare iron' code.
==== What we need in any case ====
* power management on the baseband processor through all of the stack
(though it's mostly a driver/L1 kind of thing)
== Summary / Opinion ==
It seems like running the OsmocomBB layer1 + 'mobile' as-is on the
Openmoko baseband + application processor might be the quicker road to
progress. Sure, the power consumption will be horrible as the AP will
have to be woken up for each and every SI message, neighbor cell
measurment or paging request that ew see comining in in our paging group
(even in idle mode). But then, there is always the negative impact of
using a relatively complex system, with two processors, a complex
software stack (Linux, X11, toolkit, etc.) on one of them, etc.
On the other hand, using the C1xx phones will result in a much more
widely available result. The phones can still be bought in batches of
1,000 units, and they are small enough for lots of people to carry
around. Furthermore, the battery lifetime is far beyond anything you
would ever be able to achieve on a power-hungry smartphone platform. I
believe it would be the "smart' solution, as it means we need to get
everything integrated, etc.
What does the community on this list think? Which way shoul we go?
But maybe the best thing is to actually stat working on the power
management aspects, as we will need them in both cases.
Happy hacking,
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 All,
I'd like to know if it is possible to control with osmocom the UL requests sent from the handsets. More specifically the interval between the UL request iterations when there is no response from the HLR. Also is it possible to simulate manual registration to the network i.e. keep sending UL to the same network after the 4th UL has timed out?
I guess this could be a function of the baseband chip itself but some settings are controlled by the firmware.
BR,
Todor
-----Ursprüngliche Nachricht-----
Von: Sylvain Munaut <246tnt(a)gmail.com>
> Damnit, I forgot to enable TX ... sorry about that.
>
> http://minus.com/mbiuqRunDm
Sylvain,
now it behaves much more stable!! That is awesome. Thank you. What have you changed / what was the issue?
Now I'm in the network only with a single disconnect since a few minutes. I also had the chance to make a phone-call now.
Stefan
-----Ursprüngliche Nachricht-----
Von: Sylvain Munaut <246tnt(a)gmail.com>
Gesendet: Mo 09.01.2012 14:12
Betreff: Re: random net disconn. - o2 germany - motorola c123 + c140
An: Stefan Bauer <stefan.bauer(a)cubewerk.de>;
CC: baseband-devel(a)lists.osmocom.org;
> > thank you for your time. Here is the L1-log:
> >
> > http://www.plzk.de/layer1.log
>
> Could you retry with this layer1 firmware :
>
> http://minus.com/mdAV5dFRb
I just tried it. No luck. It seems, that this FW lacks TX-support?
http://www.plzk.de/layer1-newFW.log
Stefan
-----Ursprüngliche Nachricht-----
Von: Sylvain Munaut <246tnt(a)gmail.com>
Gesendet: Mo 09.01.2012 12:37
Betreff: Re: random net disconn. - o2 germany - motorola c123 + c140
An: Stefan Bauer <stefan.bauer(a)cubewerk.de>;
CC: baseband-devel(a)lists.osmocom.org;
> > Is it possible, that i miss an important part in my setup? To be honest, i
> followed quite strictly all the informations in the public wiki.
>
> Post the L1 logs (from osmocon) ... because the log you post contain
> no low level information whatsoever (those happen on the phone and not
> on the pc software).
thank you for your time. Here is the L1-log:
http://www.plzk.de/layer1.log
Stefan
-----Ursprüngliche Nachricht-----
Von: Stefan Bauer <stefan.bauer(a)cubewerk.de>
> I moved closer to the cell. I got associated to the cell with much better
> quality. Then the channel switch was initiated by the software - without luck -
> logs attached:
I tested another provider. This time Vodafone. The rx-quality is even better:
(my cell #33 is -64)
<0004> gsm322.c:4783 Measurement result for ARFCN 16: -95
<0004> gsm322.c:4783 Measurement result for ARFCN 20: -93
<0004> gsm322.c:4783 Measurement result for ARFCN 21: -96
<0004> gsm322.c:4783 Measurement result for ARFCN 22: -92
<0004> gsm322.c:4783 Measurement result for ARFCN 25: -92
<0004> gsm322.c:4783 Measurement result for ARFCN 33: -64
<0004> gsm322.c:4783 Measurement result for ARFCN 34: -84
<0004> gsm322.c:4783 Measurement result for ARFCN 43: -87
<0004> gsm322.c:4783 Measurement result for ARFCN 44: -86
<0004> gsm322.c:4783 Measurement result for ARFCN 48: -81
<0004> gsm322.c:4783 Measurement result for ARFCN 49: -94
<0004> gsm322.c:4783 Measurement result for ARFCN 82: -94
<0004> gsm322.c:4783 Measurement result for ARFCN 86: -74
<0004> gsm322.c:4783 Measurement result for ARFCN 87: -93
<0004> gsm322.c:4783 Measurement result for ARFCN 88: -92
<0004> gsm322.c:4783 Measurement result for ARFCN 95: -92
<0004> gsm322.c:4783 Measurement result for ARFCN 123: -84
<0004> gsm322.c:4783 Measurement result for ARFCN 124: -79
<0004> gsm322.c:4691 RLA_C of serving cell: -55
<0004> gsm322.c:374 A (RLA_C (-55) - RXLEV_ACC_MIN (-106)) = 51
<0004> gsm322.c:376 B (MS_TXPWR_MAX_CCH (33) - p (33)) = 0
<0004> gsm322.c:377 C1 (A - MAX(B,0)) = 51
<0004> gsm322.c:400 C2 = C1 - CELL_RESELECT_OFFSET (0) = 51 (special case)
<0004> gsm322.c:4746 #1 ARFCN=33 RLA_C=-64
<0004> gsm322.c:4746 #2 ARFCN=86 RLA_C=-75
<0004> gsm322.c:4746 #3 ARFCN=124 RLA_C=-80
<0004> gsm322.c:4746 #4 ARFCN=48 RLA_C=-82
<0004> gsm322.c:4746 #5 ARFCN=123 RLA_C=-82
<0004> gsm322.c:4746 #6 ARFCN=34 RLA_C=-83
<0004> gsm322.c:4569 Syncing to new neighbour cell 33.
For unknown reasons, the sync fails again:
<0003> gsm322.c:469 Sync to ARFCN=33 rxlev=-68 (No sysinfo yet, ccch mode NONE)
<0003> gsm322.c:2937 Channel synched. (ARFCN=33, snr=16, BSIC=25)
<0001> gsm322.c:2958 using DSC of 90
<0004> gsm322.c:4640 Synced to neighbour cell 33.
<0003> gsm322.c:692 Starting CS timer with 2 seconds.
<0003> gsm48_rr.c:4941 Channel provides data.
<0001> gsm48_rr.c:1887 New SYSTEM INFORMATION 2
<0001> sysinfo.c:719 New SYSTEM INFORMATION 3 (mcc 262 mnc 01 lac 0x430a)
<0001> gsm48_rr.c:2012 Changing CCCH_MODE to 1
<0003> gsm322.c:702 stopping pending CS timer.
<0003> gsm322.c:2567 Relevant sysinfo of neighbour cell is now received or updated.
<0004> gsm322.c:4661 Read from neighbour cell 33 (rxlev -68).
<0004> gsm322.c:4569 Syncing to new neighbour cell 86.
<0003> gsm322.c:469 Sync to ARFCN=86 rxlev=-78 (No sysinfo yet, ccch mode NONE)
<0003> gsm322.c:2980 Channel sync error, try again
<0003> gsm322.c:469 Sync to ARFCN=86 rxlev=-78 (No sysinfo yet, ccch mode NONE)
<0003> gsm322.c:2993 Channel sync error.
<0003> gsm322.c:2998 free sysinfo ARFCN=86
<0004> gsm322.c:4640 Failed to sync to neighbour cell 86.
<0004> gsm322.c:4569 Syncing to new neighbour cell 124.
<0003> gsm322.c:469 Sync to ARFCN=124 rxlev=-83 (No sysinfo yet, ccch mode NONE)
<0003> gsm322.c:2980 Channel sync error, try again
<0003> gsm322.c:469 Sync to ARFCN=124 rxlev=-83 (No sysinfo yet, ccch mode NONE)
<0003> gsm322.c:2993 Channel sync error.
<0003> gsm322.c:2998 free sysinfo ARFCN=124
<0004> gsm322.c:4640 Failed to sync to neighbour cell 124.
<0004> gsm322.c:4569 Syncing to new neighbour cell 48.
<0003> gsm322.c:469 Sync to ARFCN=48 rxlev=-83 (No sysinfo yet, ccch mode NONE)
<0003> gsm322.c:2980 Channel sync error, try again
<0003> gsm322.c:469 Sync to ARFCN=48 rxlev=-83 (No sysinfo yet, ccch mode NONE)
<0003> gsm322.c:2993 Channel sync error.
<0003> gsm322.c:2998 free sysinfo ARFCN=48
<0004> gsm322.c:4640 Failed to sync to neighbour cell 48.
<0004> gsm322.c:4569 Syncing to new neighbour cell 123.
<0003> gsm322.c:469 Sync to ARFCN=123 rxlev=-85 (No sysinfo yet, ccch mode NONE)
<0003> gsm322.c:2980 Channel sync error, try again
<0003> gsm322.c:469 Sync to ARFCN=123 rxlev=-85 (No sysinfo yet, ccch mode NONE)
<0003> gsm322.c:2993 Channel sync error.
<0003> gsm322.c:2998 free sysinfo ARFCN=123
<0004> gsm322.c:4640 Failed to sync to neighbour cell 123.
<0004> gsm322.c:4569 Syncing to new neighbour cell 34.
<0003> gsm322.c:469 Sync to ARFCN=34 rxlev=-86 (No sysinfo yet, ccch mode NONE)
<0003> gsm322.c:2980 Channel sync error, try again
<0003> gsm322.c:469 Sync to ARFCN=34 rxlev=-86 (No sysinfo yet, ccch mode NONE)
<0003> gsm322.c:2993 Channel sync error.
<0003> gsm322.c:2998 free sysinfo ARFCN=34
<0004> gsm322.c:4640 Failed to sync to neighbour cell 34.
<0004> gsm322.c:4122 Re-select using access class with Emergency class.
<0004> gsm322.c:4142 Checking cell of ARFCN 33 for cell re-selection.
<0004> gsm322.c:374 A (RLA_C (-64) - RXLEV_ACC_MIN (-106)) = 42
<0004> gsm322.c:376 B (MS_TXPWR_MAX_CCH (33) - p (33)) = 0
<0004> gsm322.c:377 C1 (A - MAX(B,0)) = 42
<0004> gsm322.c:400 C2 = C1 - CELL_RESELECT_OFFSET (0) = 42 (special case)
<0004> gsm322.c:4198 -> Cell of is in the same LA, so CRH = 0
<0004> gsm322.c:4142 Checking cell of ARFCN 86 for cell re-selection.
<0004> gsm322.c:4164 Skip cell: There are no system informations available.
<0004> gsm322.c:4142 Checking cell of ARFCN 124 for cell re-selection.
<0004> gsm322.c:4164 Skip cell: There are no system informations available.
<0004> gsm322.c:4142 Checking cell of ARFCN 48 for cell re-selection.
<0004> gsm322.c:4164 Skip cell: There are no system informations available.
<0004> gsm322.c:4142 Checking cell of ARFCN 123 for cell re-selection.
<0004> gsm322.c:4164 Skip cell: There are no system informations available.
<0004> gsm322.c:4142 Checking cell of ARFCN 34 for cell re-selection.
<0004> gsm322.c:4164 Skip cell: There are no system informations available.
<0004> gsm322.c:4624 Syncing back to serving cell
<0003> gsm322.c:463 Sync to ARFCN=46 rxlev=-56 (Sysinfo, ccch mode NON-COMB)
<0001> gsm48_rr.c:679 MON: no cell info
<0003> gsm322.c:2980 Channel sync error, try again
<0003> gsm322.c:463 Sync to ARFCN=46 rxlev=-56 (Sysinfo, ccch mode NON-COMB)
<0003> gsm322.c:2980 Channel sync error, try again
<0003> gsm322.c:463 Sync to ARFCN=46 rxlev=-56 (Sysinfo, ccch mode NON-COMB)
<0003> gsm322.c:2993 Channel sync error.
<0003> gsm322.c:2998 free sysinfo ARFCN=46
<0003> gsm322.c:3005 Unselect cell due to sync error!
<0003> gsm322.c:498 Unselecting serving cell.
<0003> gsm322.c:3072 Loss of CCCH, Trigger re-selection.
<0003> gsm322.c:4035 (ms 1) Event 'EVENT_CELL_RESEL' for Cell selection in state 'C7 camped on any cell'
<0003> gsm322.c:823 new state 'C7 camped on any cell' -> 'C8 any cell re-selection'
<0003> gsm322.c:4334 Checking cell with ARFCN 33 for cell re-selection. (C2 = 42)
<0003> gsm322.c:4334 Checking cell with ARFCN 86 for cell re-selection. (C2 = 0)
<0003> gsm322.c:4345 Skip cell: not suitable and/or allowable.
<0003> gsm322.c:4334 Checking cell with ARFCN 124 for cell re-selection. (C2 = 0)
<0003> gsm322.c:4345 Skip cell: not suitable and/or allowable.
<0003> gsm322.c:4334 Checking cell with ARFCN 48 for cell re-selection. (C2 = 0)
<0003> gsm322.c:4345 Skip cell: not suitable and/or allowable.
<0003> gsm322.c:4334 Checking cell with ARFCN 123 for cell re-selection. (C2 = 0)
<0003> gsm322.c:4345 Skip cell: not suitable and/or allowable.
<0003> gsm322.c:4334 Checking cell with ARFCN 34 for cell re-selection. (C2 = 0)
<0003> gsm322.c:4345 Skip cell: not suitable and/or allowable.
<0003> gsm322.c:4372 Best neighbour cell with ARFCN 33 selected. (normal priority)
<0003> gsm322.c:4405 Scanning ARFCN 33 of neighbour cell during cell reselection.
<0003> gsm322.c:469 Sync to ARFCN=33 rxlev=-68 (No sysinfo yet, ccch mode NONE)
<0005> gsm48_mm.c:4329 (ms 1) Received 'MM_EVENT_LOST_COVERAGE' event in state MM IDLE, limited service
<0005> gsm48_mm.c:1059 Selecting PLMN SEARCH state, because no cell selected.
<0005> gsm48_mm.c:912 new MM IDLE state limited service -> PLMN search
Is it possible, that i miss an important part in my setup? To be honest, i followed quite strictly all the informations in the public wiki.
Stefan
