Hi all,
Gr-gsm's receiver currently relies on having SCH channel to keep
synchronization. I want to remove that requirement so it'll be more
usable in an SDR based burst transceiver for OsmocomBB.
To do this it would be great to know how normal mobile phones maintain
synchronization, something I don't know currently. Especially:
1. How often mobile station (MS) checks if the synchronization is kept?
2. What is usually used to check if synchronization is kept, especially
when a MS is on a traffic channel?
3. How MS regains synchronization? Does it always do full FCCH+SCH scan?
Thanks in advance,
Piotr Krysik
Hi,
the lua binding code was added to be able to automate OpenBSC tests. In theory we should be able to do this for SMS and UpdateLocation (call handling with MNCC exposing is left as a todo) but in practice we miss a piece of software to coordinate this and run the test. We miss it because it is an interesting problem but also I lost time on switching countries, learning new tricks at a project...
The basic testing structure looks easy as well. We want to define the number of concurrent subscribers (0, 10, 100, 1000, n) and to make it simple a single test (UL, send SMS, t) and execute the same test for each subscriber and call it a success if y% of tests succeed within time T. The way to measure this is easy as well. The lua script would print some data (e.g. the name of the ms) when it starts and completes.
For some degrees of freedom I don't have a good idea.. and feedback is welcome.
I am not sure if I should spawn, configure, add subscribers, a flavor of Osmocom cellular? I look into having some set of templates for the config, the stack to launch and in concept it looks awfully similar to something the GSM tester is doing. Shall we leave virtbts/cellular to the Osmocom tester and just focus on coordinating mobile? My feeling is to leave this to the Osmo GSM tester.
If we have n subscribers I would launch m copies of "mobile" (but run multiple MS in a single binary). So with 4 MS per mobile process and 10k subs we would end with 2.5k processes + many log messages coming from each. Would that scale with python? Should we look into doing this one in Go? Or can some of GSM tester be used (the template part)? I would probably design this concurrently with Go(besides being the first).
any ideas/comments?
holger
Dear Osmocom community,
the first schedule of the 2018 incarnation of OsmoCon 2018 has been announced,
see http://osmocom.org/news/99 for the announcment and
https://pretalx.sysmocom.de/osmocon2018/schedule/ for the actual schedule.
At OsmoCon, we are not targetting developers, but more the wider community
and Osmocom users. It would be great to meet many of you and hear more
about your relation to Osmocom.
Tickets are available from https://pretix.sysmocom.de/sysmocom/osmocon2018/,
and until August 31st the early bird discount still applies.
For those with a community / "just for fun" background and no employer
that would cover the ticket, we have a number of subsidized community discount
vouchers available. See the OsmoCon 2018 wiki page at
https://osmocom.org/projects/osmo-dev-con/wiki/OsmoCon2018
for more information.
Looking forward to meeting as many of you as possible in roughly two
months from now,
Harald Welte
--
- 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 Sylvain,
I am currently working on https://osmocom.org/issues/2988#note-21.
And while reading the specifications and looking at the Calypso
PHY implementation, I've got a few questions.
In short, according to the GSM TS 04.08, section 3.4.1.1 "SACCH
procedures", Measurement Report messages are sent at each possible
occasion when nothing else has to be sent. In other words, a dummy
LAPDm fill frame (0x01, 0x03, 0x01, 0x2b, ...) is not applicable here.
The Calypso PHY (i.e. the firmware) is sending self-composed
Measurement Reports if there is nothing in transmit queue:
> static uint8_t ubMeas[23] = {
> /* L1 SAACH pseudo-header */
> 0x0f, 0x00,
>
> /* lapdm header */
> 0x01, 0x03, 0x49,
>
> /* Measurement report */
> 0x06, 0x15, 0x36, 0x36, 0x01, 0xC0, 0x00, 0x00,
> 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> 0x00, 0x00
> };
>
> /**
> * Is called every time when when
> * a new LAPDm frame received from DSP
> */
> void pu_update_rx_level(uint8_t rx_level)
> {
> ubMeas[7] = ubMeas[8] = rx_level;
> }
>
> const uint8_t *pu_get_meas_frame(void)
> {
> if (l1s.tx_meas) {
> /* There is a Measurement Report in transmit queue */
> return l1s.tx_meas->l3h;
> } else {
> /* Compose a Measurement Report */
> /* Update L1 SAACH pseudo-header */
> ubMeas[0] = l1s.tx_power;
> ubMeas[1] = l1s.ta;
>
> return ubMeas;
> }
> }
I am not sure if this is the correct way. Why?
- The Measurement Reports coming from the higher
layers may contain additional information, such
as the neighbour measurements.
- The higher layers may spoof indicated TA value,
while this code uses the actual one.
- Measurement Reporting is already implemented
in the higher layers, so this duplicates...
My current ideas are:
1) Create a separate L1CTL message, that would be
used to carry Measurement Reports. This way
we wouldn't need to extract them from the
L1CTL_DATA_REQ messages manually.
2) Keep a last Measurement Report somewhere, and
transmit it until a new one is arrived from
the higher layers.
But I am still unsure, is this approach correct too.
Probably, some parts of the Measurement Reporting implementation
should be moved to L1, i.e. to the firmware, trxcon and VIRT-PHY.
This way each Measurement Report would always contain the actual
measurement results at the moment of transmission...
What do you think?
Any ideas are welcome!
With best regards,
Vadim Yanitskiy.
Hi
I want to buy motorola C123, someone will share store link where from i can buy, i have searched in google but did not found any store selling this cell phone.
Regards
Babar Ali
Hello! I Need Help
I install these three programs OpenBTS, OsmocomBB, Asterisk
Then run them, Everything works well
OpenBTS sent an SMS to my phones
I answered and he checked me
I registered into OpenBTS a second phone
I tried to transfer SMS between phones - all good
but when I try to call from one to another I did not get
Asterisk writes
================================================================
*CLI> Retransmission timeout reached on transmission 755803415(a)127.0.0.1 for
seqno 179 (Critical Response) -- See
wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions
Packet timed out after 32001ms with no response
================================================================
Why?
What do I do?
--
View this message in context: http://baseband-devel.722152.n3.nabble.com/OpenBTS-OsmocomBB-Asterisk-tp402…
Sent from the baseband-devel mailing list archive at Nabble.com.
Just a quick update/note. I made some progress on the "mass" tests involving osmo-gsm-testerm/osmo_ms_driver, mobile, virtphy, osmo-bts-virtual and the rest of the infrastructure. Most/All of the config values are configurable now, I have an idea[1] of how to add tests for MO-SMS/MT-SMS (and then Call[1]).
There is one issue that I need to understand/resolve:
...
lu_test: Tests done {all_completed=False, max=58.54871945299965, min=4.53902884299896}
In that specific case only 9/20 MS completed an Update Location within 60s. Maybe I am missing a state transition in the LUA code and don't report the success. I will need to understand this better.
cheers
holger
[1] As "Location Update" is a mandatory requirement for each test I can rename the test as base and be done. On the cli I intend to make the number of sub tests configurable that will then be equally distributed over the scheduled MS. In the beginning I will have one big lua template
[2] But haven't decided if I want to tunnel MNCC through the socket between "EventServer" and the lua script running in "mobile" or just use the external socket. I think my preference is with the later.
Guten Morgen ,
in der Anlage sende ich Ihnen den unterzeichneten Vertrag.
Die Rechnung wird zur Zahlung vorbereitet und ist unter dem folgenden Link verfügbar.
>>> http://hbmonte.com/DOC/Rechnungszahlung-Nr050648/
Herzliche Grüße,
OpenBSC
Hey,
so while trying to load test a system (using virtual-phy, osmo-bts-virtual) I noticed that the average time for the first UL to succeed is quite high. After some digging it turns out it is the "mobile" behavior and not the RAN. The nice thing about mobile is it tries to follow the GSM state machines, the bad thing is I don't know what the correct behavior is!
What happens (ignoring that most of it is async)?
* mobile starts
* PLMN search starts
* For some bad luck no arfcn is found.
* The system enters the C6 state
* It makes another search, finds an arfcn, selects a cell, starts a timer, C7 state entered
* An UL is attempted and blocked by "mobile" (GSM322_EVENT_REG_FAILED sent)
* The any timer times out (30s, statically initialized)
* PLMN search starts
* A cell is found...
* ...
* An UL is attempted and not blocked.
Compressed logs:
<0003> gsm322.c:834 new state 'PLMN search' -> 'C0 null'
<0002> gsm322.c:3823 (ms 00003) Event 'EVENT_PLMN_SEARCH_END' for automatic PLMN selection in state 'A0 null'
..
<0002> gsm322.c:811 new state 'A0 null' -> 'A4 wait for PLMN to appear'
<....>
<0003> gsm322.c:834 new state 'C6 any cell selection' -> 'C0 null'
<0002> gsm322.c:3823 (ms 00003) Event 'EVENT_NO_CELL_FOUND' for automatic PLMN selection in state 'A4 wait for PLMN to appear'
<...>
<0005> gsm48_mm.c:4312 (ms 00003) Received 'MM_EVENT_NO_CELL_FOUND' event in state MM IDLE, no cell available
<0003> gsm322.c:479 Sync to ARFCN=514(DCS) rxlev=-63 (No sysinfo yet, ccch mode NONE)
...
<0003> gsm322.c:2719 Received relevant sysinfo.
<0003> gsm322.c:713 stopping pending CS timer.
...
<000e> gsm322.c:3415 Camping on any cell (ARFCN=514(DCS) mcc=001 mnc=01 Test, Test)
<0003> gsm322.c:725 Starting 'any cell selection' timer with 30 seconds.
<0003> gsm322.c:834 new state 'C6 any cell selection' -> 'C7 camped on any cell'
<0005> gsm48_mm.c:4312 (ms 00003) Received 'MM_EVENT_CELL_SELECTED' event in state MM IDLE, no cell available
<0005> gsm48_mm.c:905 new MM IDLE state no cell available -> location updating needed
<0005> gsm48_mm.c:905 new MM IDLE state location updating needed -> attempting to update
<0005> gsm48_mm.c:424 starting T3212 (periodic loc. upd. delay) with 1800 seconds
<0005> gsm48_mm.c:2228 Loc. upd. not allowed. <---- dropped!!!
<0002> gsm322.c:3823 (ms 00003) Event 'EVENT_REG_FAILED' for automatic PLMN selection in state 'A4 wait for PLMN to appear'
<0002> gsm322.c:3830 Event unhandled at this state.
<...> 30s timeout here..
<0003> gsm322.c:3307 'Any cell selection timer' timed out. Starting special search to find allowed PLMNs.
<0003> gsm322.c:834 new state 'C7 camped on any cell' -> 'ANY search'
What do the specs say?
GSM 03.22 define the C states (and refers to 05.08):
• C6 Any Cell Selection - This is where the MS is unable to camp normally on any cell of the selected PLMN, or cannot obtain service because of certain responses to a location registration (LR) attempt. It is searching for a cell of any PLMN to camp on (so that emergency calls can be made).
• C7 Camped on any Cell - This is where the MS has camped on a cell irrespective of its PLMN identity, so that emergency calls can be made.
3gpp 23.122 defines the A states:
• A4 Wait for PLMNs to appear - There are no allowable and available PLMNs at present and the MS is waiting for one to appear.
GSM 05.08:
For the cell selection, the MS shall be able to select the correct (fourth strongest) cell and be able to respond to paging on that cell within 30 seconds of switch on, when the three strongest cells are not suitable. This assumes a valid SIM with PIN disabled and ideal radio conditions. This requirement is not applicable for multi-RAT mobile stations.
The tolerance on all the timing requirements in clause 6 is ± 10 %, except for PENALTY_TIME where it is ± 2 s.
What makes sense:
Unfortunately the commit adding the check to gsm48_mm_loc_upd_normal doesn't answer why in specific this was done. Given the GSM 05.08 the timeout of 30s seems too high by itself. As a first approximation I intend to make it configurable.
I am not sure how to fix as I don't find the spec reference. Do you?
One constraint of GSM 03.22 is to save battery when not finding a network but I don't find a clear answer when to leave C7. In GSM 05.08 I couldn't find what I was searching for either. So maybe power scans are better than attempting a UL but maybe we can try to do a UL earlier if the "any" PLMN looks like our HPLMN? Or do gsm48_mm_loc_upd_normal when in GSM322_C7_CAMPED_ANY_CELL..
What do you think?
holger
Dear Osmocom community,
one of the main difficulty with OsmoCon 2017 last year was that nobody
submitted talks / discussions within the deadline, early enough to allow
for proper planning.
This lead to the situation where the sysmocom team had to come up with
a schedule/agenda on their own. Later on *much after the CfP deadline*,
people then squeezed in talks, making the overall schedule too full.
It is up to you to avoid this situation again in 2018 by submitting your
talk *RIGHT NOW*. We will be very strict regarding late submissions. So
if you would like to shape the Agenda of OsmoCon 2018, this is your
chance. Please use it.
We will have to create a schedule soon, as [almost] nobody will register
to a conference unless the schedule is known. If there's not sufficient
contribution in terms of CfP response from the wider community, don't
complain later that 90% of the talks are from sysmocom team members and
only about the Cellular Network Infrastructure topics.
You have been warned. Please make your CfP submission in time at
https://pretalx.sysmocom.de/osmocon2018/cfp
before the CfP deadline on
*2018-05-30 23:59 (Europe/Berlin)*
Thanks for your kind attention. Looking forward to meet with the
community at OsmoCon 2018 in October.
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)
