baseband-devel January 2012

baseband-devel@lists.osmocom.org

38 participants
55 discussions

AW: Re: 3GPP - paging references
by Stefan Bauer 12 Jan '12

12 Jan '12

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

1 0

3GPP - paging references
by Stefan Bauer 12 Jan '12

12 Jan '12

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

2 1

Bounce action notification
by mailman＠lists.osmocom.org 12 Jan '12

12 Jan '12

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.

1 0

Creating a real usable phone using OsmocomBB
by Harald Welte 11 Jan '12

11 Jan '12

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)

14 27

Control Update Location with osmocom
by Todor Pirov 11 Jan '12

11 Jan '12

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

1 0

AW: random net disconn. - o2 germany - motorola c123 + c140
by Stefan Bauer 09 Jan '12

09 Jan '12

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

4 4

Re: random net disconn. - o2 germany - motorola c123 + c140
by Stefan Bauer 09 Jan '12

09 Jan '12

-----Ursprüngliche Nachricht----- Von: Sylvain Munaut <246tnt(a)gmail.com> > I didn't change anything, I just compiled the git. > > For some unknown reason, some ARM toolchain produce "half working" > binaries ... we have no idea why that happens. For me, i'm happy now as i can debug and test this gsm stuff further. thank you again. > What's the toolchain you use ? Well, i just used the following sources and put them together: wget http://www.gnuarm.com/binutils-2.17.tar.bz2 wget http://www.gnuarm.com/gcc-4.1.1.tar.bz2 wget http://www.gnuarm.com/newlib-1.14.0.tar.gz wget http://www.gnuarm.com/insight-6.5.tar.bz2 wget http://ftp.gnu.org/gnu/gdb/gdb-6.7.tar.bz2 According to some german howto from here: http://www.alphapogo.de/ > Could you send be the binary you compiled ? Sure - please find the binary here: http://www.plzk.de/layer1.compalram.bin 4479603075372ce89c215178a9ad48f3 layer1.compalram.bin Stefan

2 1

Re: random net disconn. - o2 germany - motorola c123 + c140
by Stefan Bauer 09 Jan '12

09 Jan '12

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

2 1

AW: random net disconn. - o2 germany - motorola c123 + c140
by Stefan Bauer 09 Jan '12

09 Jan '12

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

2 1

AW: random net disconn. - o2 germany - motorola c123 + c140
by Stefan Bauer 09 Jan '12

09 Jan '12

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

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel January 2012