Hi,
Some of my sent SMS are not received by my mobile and I try to figure out
if this is a problem with my virtual layer 1, configuration or
something in the layers 2+.
I use:
osmo-nitb: 1 subscriber in hlr (id 1, ext 017519191919)
osmo-bts: virt-phy, arfcn 666, TS0=CCCH+SDCCH4, TS1=SDCCH8
MS layer23 app mobile: is the subscriber from osmo-nitb
MS layer1 virt-phy: virtual gsmtap layer between bts and mobile
I want:
Send a sms to subscriber 017519191919.
osmo-nitb VTY:
OpenBSC# subscriber id 1 sms sender id 1 send Test
I have 2 outcomes, first one is the failure. See
https://www.dropbox.com/s/eunpfioq518t09a/mobile--ms-virt--bts-virt--bsc-ni…
for the pcap. Do not wonder about the duplicated gsmtap messages from mobile,
the ones to ip 225.0.0.1 are over virt-phy layer, the ones to localhost from
the gsmtap logging option from mobile. Filter them out via "gsmtap &&
(ip.dst != 127.0.0.1)".
602-613: RR channel establishment with RA and IA as reaction to paging in 590
627,631: SABM from BTS to establish async balanced mode on SAPI3 (SMS)
and the ACK from MS
656,684,699: I-Data frames on SAPI3 containing the sms
660,688,703: ReceiveReady's from MS (That ACK all I-frames before
N(R)-1 as far as I understood)
For me, that looks good and I really do not understand why the MS will
not answer with the CP-ACK/RP-ACK
after receiving the SMS Data in 699.
The LAPDM link will stay up for some more time and be used by the
network for retransmission of the sms (1149),
but MS will never react to it on the SMS layer (CP-ACK, RP-ACK).
Here is the console log for the mobile
(https://www.dropbox.com/s/6gug5cd4up5qv7y/mobile--ms-virt--bts-virt--bsc-ni…).
The paging is answered in line 378:
Fri Mar 10 10:42:06 2017 DLLAPD <0012> lapd_core.c:793 SABM(E)
received in state LAPD_STATE_IDLE
Second outcome is a successfully sent sms from network to ms. See
https://www.dropbox.com/s/ghdn7pc0j4vifbe/mobile--ms-virt--bts-virt--bsc-ni…
for the pcap. What is different here? There is no paging, but the sms
is sent within the dedicated
channel used for the location update initiated by the phone started
up. Why there is another outcome, I don't know.
169-181: RR channel establishment with RA and IA as part of mibiles
startup routine to make location update
188,416: Location udpdate procedure on SAPI0
230,234: SABM from BTS to establish async balanced mode on SAPI3 (SMS)
and the ACK from MS
396,444: I-Data frames on SAPI3 containing the sms
400,449: RR's from MS
450: CP-ACK for BTS
482,499: RP-ACK I-Frames for Network (osmo-nitb)
Again, the console log of the mobile
(https://www.dropbox.com/s/cujsn40d43g6wxk/mobile--ms-virt--bts-virt--bsc-ni…).
The SABM on SAPI3 on downlink is received in line 206:
Fri Mar 10 11:06:13 2017 DLLAPD <0012> lapd_core.c:793 SABM(E)
received in state LAPD_STATE_IDLE
The signaling looks quite similar in both cases, but one time the
mobiles sms handler responds to CP-DATA msg containing the SMS, the
other time not.
Can someone find an error in the signaling I did not see?
Is there a known Bug? To be honest, I last merged my branch with
master some time ago (~ Jan 18 2017) and thus did not update osmo-nitb
and
the libraries since then to avoid compatibility problems. Have there
been recent changes that could cause that behavior?
Thank you and Kind Regards,
Sebastian
I tried to install CalypsoBTS have libosmocore installed, osmo-bts osmobsc,
libosmo-netif, libosmo-abis, ortp, trx, libosmo-dsp everything went without
errors, following the instructions I created: touch ~/.osmocom/open-bsc.cfg
, then when you run : osmo-nitb -c ~/.osmocom/open-bsc.cfg-l
~/.osmocom/hlr.sqlite3-P-C --debug=DRLL:CC:MM:RR:RSL:NM shows me:<0005>
bsc_init.c:498 Failed to parse the config file:
'/root/.osmocom/open-bsc.cfg' file tried to create as administrator but
without success , pleas help me
--
View this message in context: http://baseband-devel.722152.n3.nabble.com/Calypso-BTS-tp4026753.html
Sent from the baseband-devel mailing list archive at Nabble.com.
Dear all,
I've been asked by a number of pepole about a possible Osmocom village at the
CCC Camp 2019. I personally didn't really have any plans, but given related
e-mails and "encouragement" I went ahead and registered an "Osmocom Village",
see
https://signup.c3assemblies.de/assembly/3b8f7aa2-95d5-4c44-aadc-de8f2680e9c3
I also created a wiki page (as nobody else did, despite earlier discussion on IRC,
SCNR) for coordinating related efforts at
https://osmocom.org/projects/osmo-dev-con/wiki/CCC_Camp_2019
One of the bigger questions is about having a tent as well as some tables/benches
to sit on and work. The Camp orga team nas been negotiating rates with a tent
rental company, but to be honest I'm rather surprised by the extremely steep
pricing. The smallest possible tent (6m x 3m) would cost 825 EUR. I'm not
sure we want to raise that amount of money? Even if we'd be 10 people sharing
it, its still 82.50 EUR per person. And that excludes any tables/chairs.
I'm attaching the relevant parts of a mail from the assemblies orga team FYI.
Please note there also is some kind of fragmentation / overlap with the
team planning to run the GSM/3G networks at the camp, see Lynxis'
related post at
https://lists.osmocom.org/mailman/private/osmocom-event-orga/2019-June/0003…
It's questionable whether it makes sense to have tow distinct
'villages', but given that e.g. I don't know anyone of that singularity
city, I'm not sure if we'd either be welcome there, nor whether we'd
want to associate us with them? Also, while the GSM network operation
for sure has good reasons to mingle with the POC and whatever facilities
they have, I'm not sure if the wider Osmocom community attendees
unrelated to the GSM network operation wouldn't just be a
disturbance/nuisance.
In the end, to be honest, I personally do not feel I have the time and
mental capacity to take on any additional tasks in terms of organizing
anything. I just created the entry in c3assemblies as I was asked to,
and I similarly created the related mailing list and wiki page.
So please, anyone interested in making an Osmocom village happen one way
or another, step up [and continue this discussion on the
camp2019-village(a)lists.osmocom.org mailing list, without crossposting
everywhere else :)
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 all!
sysmocom has obtained a first batch of 10 GTM-900B with some
FPC-to-2.54mm-breakout adapters from songbosi. They have just
arrived yesterday in Berlin. I'm happy to make them available
for free to [known/existing] Osmocom develoepers/contributors.
Let me know if you're interestd and we'll send you an envenlope, likely
mid next week due to the upcoming extended whitsunday weekend.
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 Vadim,
I'm currently facing the problem of testing hand-over related channel-activation
in OsmoBTS. Three are various rules about how this has to be done, and a closer
look indicates that both osmo-bts-trx as well as osmo-bts-sysmo don't get that
right at all.
I'd like to write TTCN-3 tests as part of BTS_Tests.ttcn, which uses L1CTL
to control a (virtual or real) L1 for the MS side of testing the BTS.
To break this down to low-level requirements in terms of MS capabilities:
* switch to a different ARFCN
* switch to a speciifed timeslot
* change the synchroniztaion (in terms of where we currently are in the TDMA
multiplex) to a given neighbor cell. The MS will have performed neighbor
measurements before, and as part of that will hav received FCCH + SCH and
hence know the timing both in terms of carrier freq as well as TDMA position
[none of this is relevant for a fake_trx + trxcon setup]
* ability to enable only the receiver for the main channel (SDCCH/FACCH), but
suppress any reception (or passing up of received) SACCH.
* ability to transmit RACH burst[s] in uplink on that new dedicated channel
* ability to later on enable full Rx/Tx of all logical channels on that dedicated
channel
I've looked at the jolly/handover branch from 2013, and rebased that on top of current
master, the result can be seen in laforge/jolly_handover_rebase
Change-Id Iadbc47f006d1f8a019822aedee180814de13cb2d specifically adds new flags
to DM_EST_REQ to
* disable uplink transmission
* use the sync information of a neighbor cell
I would like to get at least that change to L1CTL merged to master, and while
doing that, update all implementations of L1CTL at the same time. It may make
sense to also merge Change-Id I792b52d9bf115a2def9720eed3d62982d8cdbe00 while
at it, which is required for neighbor channel measurements + reporting.
We should also use that opportunity to introduce some kind of versioning support
to L1CTL, to ensure future extensions of the protocol can be made in a way where
incompatibility can at least be detected at runtime.
Now the next question is how to this will impact trxcon/fake_trx. AFAICT,
there is a comment in trxcon hinting that the TRX TUNE comamnd of a DM_EST_REQ
would fail if there was already and established channel before. Is that correct?
If so, what is the suggested/recommended way to get trxcon to support at least
the minimum of what's required for handover in a virtual environment?
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)