- baseband-devel - lists.osmocom.org

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

14 Jan '12

-----Ursprüngliche Nachricht----- Von: Sylvain Munaut <246tnt(a)gmail.com> Gesendet: Fr 13.01.2012 18:24 Betreff: Re: 3GPP - paging references An: baseband-devel(a)lists.osmocom.org; > >> Are you talking about a hardware modification of the motorola phone > > > > http://bb.osmocom.org/trac/wiki/Hardware/FilterReplacement > > Note that to receive a phone only a few meters next to you, it's not > necessary. The filters aren't that good. Thank to you point this out. I'm not interested in traffic from other phones. What i miss from the wiki or maybe just havent found yet is a statement whether i need to modify osmocom's default firmware to see uplink-traffic? (i want to see the MS response to a paging call) to understand the process of the imm.ass from BTS. Have a nice weekend stefan

1 0

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

13 Jan '12

Hi Peter, I just use the motorola to listen to my providers arcfn. Then i watch for traffic from my regular non-osmocom cell phone operating in the same cell. Are you talking about a hardware modification of the motorola phone to receive also uplink or just some software 'tuning'? I'm the transmitter in my case. Thank you Stefan ----- Ursprüngliche Nachricht ----- Von: Peter Stuge <peter(a)stuge.se> Gesendet: Freitag, 13. Januar 2012 14:47 An: baseband-devel(a)lists.osmocom.org Betreff: Re: 3GPP - paging references Stefan Bauer wrote: > I could match the informations from imm.ass (downlink) against the > paging response (uplink) on sdcch right? Anyway i still see no way > to listen to uplink traffic on sdcch without usrp-hardware. You already know what you send. If you want to listen to what someone else sends you indeed need a receiver. The Motorola phone can be modified to receive also uplink, but if the transmitter is far away it might not work anyway. //Peter

3 2

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

13 Jan '12

My information is from 'decoding gsm' master thesis from glendrange, hove, hvideberg (2010) norwegian university of science and technology, page 92, figure 5.4. I,m getting closer to understand the process of assignment if i understand you correctly now. I could match the informations from imm.ass (downlink) against the paging response (uplink) on sdcch right? Anyway i still see no way to listen to uplink traffic on sdcch without usrp-hardware. Greetings stefan ----- Ursprüngliche Nachricht ----- Von: Sylvain Munaut <246tnt(a)gmail.com> Gesendet: Freitag, 13. Januar 2012 14:12 An: Stefan Bauer <stefan.bauer(a)cubewerk.de> Cc: baseband-devel(a)lists.osmocom.org Betreff: Re: Re: 3GPP - paging references Hi, > I just red that if early assignment is used (non-oascu) in a ms terminating call, there is no channel request on RACH by ms. ??? !!! ??? Where would you have read that in the spec ? > I still dont quite get then howto match imsi/tmsi to an immediate assignment. You can't ... I just said so in the previous mails ... There is no indication in the imm.ass that would allow you to know for which mobile identity a channel is intended. You can only know if it matches _your_ request (by matching time and random reference) Cheers, Sylvain

3 2

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

13 Jan '12

Sylvain, I just red that if early assignment is used (non-oascu) in a ms terminating call, there is no channel request on RACH by ms. I still dont quite get then howto match imsi/tmsi to an immediate assignment. stefan ----- Ursprüngliche Nachricht ----- Von: Sylvain Munaut <246tnt(a)gmail.com> Gesendet: Donnerstag, 12. Januar 2012 18:30 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

2 1

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

13 Jan '12

-----Ursprüngliche Nachricht----- Von: Joshua Lackey <jl(a)thre.at> Gesendet: Fr 13.01.2012 01:09 Betreff: Re: AW: Re: 3GPP - paging references An: Stefan Bauer <stefan.bauer(a)cubewerk.de>; > On 01/12/2012 01:05 PM, Stefan Bauer wrote: > > 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. > > Call yourself 10 times. The TMSI that appears 10 times will be yours. > (With a high probability anyway.) Hi Jushua, i don't see a way to really narrow this down by this "technique". For example in my cell, the paging traffic is very high, so there are always several pagings with the same amount. Also if i do 10 calls, i do not get put through after the first paging-request on all attempts so this is not quite precise. Am i wrong? Stefan

1 0

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

12 Jan '12

-----Ursprüngliche Nachricht----- Von: Sylvain Munaut <246tnt(a)gmail.com> > 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). Sylvain, so it goes like this: ? 1. BSC starts paging MS by either TMSI/IMSI (Paging1: Normal paging chan any to imsi M(262073948077454)) 2. MS sends channel request procedure to BSC over RACH (MS uses special(random) parameters inside this request) (is there a way to see the RACH-traffic in the "air" with regular tools?) 3. BSC sends Immediate Assignment message to MS and repeates the random parameters from request (GSM48 IMM ASS (ra=0x0f, chan_nr=0x49, ARFCN=667, TS=1, SS=1, TSC=5)) Greetings Stefan

1 0

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