Hi there! LaF0rge made me some suggestions for a better troubleshooting,
so here are the logs in .log format, since the previous email wasn't
readable.
I'm attaching the RSL+OML pcap file.
Please let me know if someone knows how to connect this nanobts =)
Cheers!
Hi!
Next to the announcement (http://osmocom.org/news/75) I've put together
some guide in the wiki as to how the Virtual Um interface can be used
with the osmo-bts-virtual, virtphy and mobile programs running all on
your local PC:
https://osmocom.org/projects/cellular-infrastructure/wiki/Virtual_Um
Feel free to try it out and/or improve the wiki page and/or let me know
if something is not sufficintly clear. I intentionally don't want to
repeat general information about configuring OsmoNITB or using
OsmocomBB. The above-mentioned page should only document those aspects
that are different from the classic setup with real hardware.
I'm now investigating some more of the bugs I'm starting to find with
using the VirtualUm interface from my related TTCN-3 testsuite, at this
time particularly https://osmocom.org/issues/2380
Will document that testsuite once it can actually run as expected.
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!
Some of you will have alrady noticed, over the last few days I reviewed,
cleaned up, submitted and merged the virtual Um interface support on
both the phone side (OsmocomBB) as well as on the BTS side (OsmoBTS).
Thanks to Sebastian Stumpf for working out most of the related code,
after my initial attempt on this got stalled more than 1.5 years ago.
This means that you can now run a complete circuit-switched GSM network
without posession of any real hardware or use of any radio waves. While
that takes away almost all the fun for some of us (I would typically
agree), it opens up possibilities, particularly in terms of testing.
If anyone wants to play with it, it's actually very easy:
* build osmo-bts and the rest of the network-side code (I don't think
osmo-bts-virtual is part of the nightly Osmocom packages yet, sorry)
* run osmo-bts-virtual with a config file (example included in osmo-bts.git)
* make sure you have matching unit_id, band, ... between BTS and
BSC/NITB, just like with real hardware
OsmoBTS will start to send downlink BCCH / CCCH frames to a multicast
IPv4 address (default: 239.193.23.1) to the usual GSMTAP port 4729. If
you don't have any specific multicast routing set up, this will be
visible with TTL=1 on the network device of your default route. You
should see the GSMTAP frames in wireshark.
On the OsmocomBB side, simply start the virt_phy binary. It replaces
your calypso based phoen and its firmware and offers the L1CTL socket to
the "layer23" programs like "mobile". Once virt_phy is running, you can
start "mobile" just like with real hardware. The phone will scan the
multicast frames for BCCH messages, build up a list of currently
received BTSs and then perform normal cell selection followed by
location update.
Everything from this point on is just normal. You cannot make voice
calls, but any signaling related transactions (LU, SMS, USSD, even call
signalling) should work. Voice is missing as there is no format
specified on how to transmit FR/EFR/HR/AMR frames over GSMTAP yet.
If somebody plays with this, I would really appreciate if they could
update the Osmocom wiki with a guide/howto on how to use such a setup.
My personal plans are to use this for verification/testing of those bits
that are difficult in a true end-to-end setup like osmo-gsm-tester.
That includes:
* simulation of massive amount of phones, more than one can easily set
up in a lab and connect to USB + RF cabling.
* verification of SYSTEM INFORMATION messages, particularly in response
to different config files, ensuring that all related bits are set
correctly at all times, even after making dynamic updates
* verification of the PAGING code, i.e. that paging load is correctly
reported, paging messages are structured correctly, ...
* exhausting all channels using simulated phones, verification of
IMM.ASS.REJECT being sent ins such cases
* verification of TA loop
* verification of uplink power control loop
* verification of radio link timeout
* testing of emergency calls, which is very critical with real phones as
there's always some possible leakage into real networks
* verification of correct CBCH messages
* verification of LAPDm contention resolution (two phones selecting same
RACH value and going both on same dedicated channel)
* verification of measurement reporting (Um vs. RSL)
* verification of downlink RF power ramping
This will of course take some time, but I'm already making good progress
implementing some SYSTEM INFORMATION test code.
In case somebody wants to join in on any of the above topics (or has
even more ideas on what kind of tests he would want to implement), feel
free to follow up so we can coordinate.
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,
I'm using osmo-nitb in a testing environment and I've soon received a
request to enable SMS delivery reports.
After looking on the user manual, I couldn't find anything related to this.
I've also enabled debug logging and tried to grep for something like that
when sending a SMS between two handsets that have SMS delivery reports
enabled, without finding out anything. (SMS delivery reports tested and
worked on a public telephony system, for those two handsets)
Is there such an option available in osmo-nitb to enable delivery reports?
---
Thank you,
Stefan
Today I checked the new AoIP core network using an old Nokia 1100 handset,
which confronted me with codecs.
The Nokia 1100 says it is capable of FR2, FR1, HR1:
Channel Type - (Speech)
Element ID: 0x0b
Length: 5
0000 .... = Spare bit(s): 0x00
.... 0001 = Speech/Data Indicator: Speech (1)
Channel Rate and Type: Full rate TCH channel Bm. Prefer full rate TCH (8)
1... .... = Extension: Additional Octet
.001 0001 = Permitted speech version indication: GSM speech full rate version 2 (GSM EFR) (0x11)
1... .... = Extension: Additional Octet
.000 0001 = Permitted speech version indication: GSM speech full rate version 1 (GSM FR) (0x01)
0... .... = Extension: Last Octet
.000 0101 = Permitted speech version indication: GSM speech half rate version 1 (GSM HR) (0x05)
The "stock" osmo-bsc.cfg I was using so far had only HR3 configured. So I
naively thought, let's do:
codec-list hr3 fr2 hr1
But OsmoBSC says: "Can not have full-rate and half-rate codec." Curious, is
that a hard limitation? I'm not at all familiar with the reasons. Will we never
be able to mix FR and HR? Why then does TCH/F_TCH/H_PDCH exist?
Then I picked:
codec-list hr3 hr1
That worked, but no audio: the Samsung Galaxy got HR3 and the Nokia HR1 (the
BTS was configured for only TCH/F channels, so instead the Nokia actually got
assigned an FR1 channel). The call was established but no audio worked. I
believe in the OsmoNITB we used to complain in the log that we don't transcode
in such a situation, and the call was aborted...
When I pick
codec-list hr1
then the call works between the handsets. Again both get assigned FR1 on TCH/F;
if I configure the BTS to use TCH/H instead, both indeed get assigned HR1 as
expected.
All in all an interesting situation, which appears to mean that we practically
can't allow the newer codecs alone because older handsets would not work, and
we can't allow both because each side may pick a different one.
Should we wait until we know both sides' codecs and consolidate with each other
to pick matching ones before assigning? Is that a "late assignment" as in
issue "avoid mismatching TCH/F vs TCH/H pchan types"?
https://osmocom.org/issues/1778
But what if no match can be found? only MGW transcoding will solve all
situations I guess. Are we planning to do that, also with IuUP in mind?
https://osmocom.org/issues/1936https://osmocom.org/issues/1937
~N
I have created a fresh osmo-msc repository as a copy of openbsc.git, and pushed
the first few patches for gerrit review to move to our "new" Osmocom CN:
https://gerrit.osmocom.org/#/q/topic:vlr
As suggested before, osmo-msc will see code review and patches merged for VLR,
3G and AoIP, and so will form the basis for creating osmo-bsc, osmo-mgw and
osmo-sgsn, as distinct repositories replacing the current openbsc.git.
All further development happening in openbsc.git from now on will have to be
applied to the new repositories later. Keep that in mind, and maybe postpone
larger conflict prone efforts for later.
The review process could take some effort. Some of the commits are one
collapsed commit of fairly large development efforts. Normally, commits should
be small, but in the case of completely refactoring an entire section of the
code (VLR) or adding a completely new feature (IuCS, AoIP), it doesn't really
help to see incremental back-and-forth changes with intermediate errors and
fixes. I decided to collapse the errors with their fixes, and to save the
effort of logically plucking apart the large commits, since they anyway only
make sense as a whole. If necessary for review, we can still do so.
Despite the mass of changes, please do look closely. Parts of the new code have
possibly been hacked up in a preliminary fashion and were forgotten to
implement properly later -- this will become our new Osmocom master branches,
the stable releases and our main development arena, so do apply your scrutiny
and let's fix early what we can fix now.
The other repositories (osmo-{bsc,mgw,sgsn}) also exist already, and I am
preparing to make them work as separate entities after the code review, on
respective neels/split branches.
Each fresh repository contains the *full* openbsc.git history.
The option of relying on grafts to include the old openbsc.git history when
needed has been mentioned, but so far was more or less turned down. It is still
possible to change that. The openbsc.git history is about 9 Mb -- not too
large, so IMHO best to keep it with each separate repos to ease log browsing,
git blame and so forth. OTOH, we have it four times, which makes 36 Mb of
duplicated history. If anyone still prefers a flat snapshot migration with a
wiki page describing how to graft in the old history, we may discuss and change
that.
No branches have been migrated except the current aoip development branch that
is going to become the new master.
All tags are included, except: the signed '0.1.2' openbsc version tags are
replaced by 'openbsc/0.1.2' tags pointing at the same revisions, so that we
don't confuse them with the new version tags in each new project.
Preliminarily, the last openbsc.git master has been tagged as version 0.0.1 in
order to get *something* out from git-version-gen, useful for referencing a
version of the new libosmo-mgcp library in osmo-{msc,bsc} configure.ac.
We still need to decide whether to start versioning afresh or continue from the
openbsc.git version scheme. openbsc.git ended with 0.15.0. My personal choice
would be to bump the major and start from 1.0.0 in each new repository.
~N
Dear all,
I have one sysmo2050, with the GSM running fine. However, i would like to
test GPRS data transmission, I was following this setup page (
https://osmocom.org/projects/cellular-infrastructure/wiki/OpenBSC_GPRS#Open…),
but i couldnt make it work. Anyone has done it before / can help me?
Thanks beforehand,
Marcus Dias
UFPA - Lasse - LaPS
Hi,
recently my modem with an already known SIM got a location update
reject, because the procedure timed out. So I looked more
into the location updates.
How openbsc location update works:
MS Network
LOC REQ ->
<- Identity Req IMSI
Identity Resp IMSI ->
<- Identity Req IMEI
Identity Resp IMEI ->
<- LOC ACCEPT
OpenBSC is using a Timeout (5 sec) for the completion of location
update.
So let's say we trigger for unknown reason the timeout (e.g. RF
problem).
MS Network
LOC REQ ->
<- Identity Req IMSI
(No response)
<- LOC Reject! cause 13 / No roaming allowed.
If the MS receive it, it will put our network on it's blacklist and
won't try it again until power cycled.
We could change reject cause to something different [1], but
we might want to reject foreign SIMs not to try our network again.
The problem here is that openBSC use the same configuration to reject
unknown SIMs as well for timeouts.
But I think this timeout should be removed. 04.08 doesn't
describe a timeout on location update request on network side. But it
describes other timeouts:
04.08 describes:
- T3260 auth req. sent, wait until response (12 sec)
- T3270 identity req. sent, wait until response (12 sec)
I think we should implement both timers and drop the RR connection if
it fires.
I'm unsure if it's needed: But OpenBSC could count un-successful
location update req. Reset counter if it's succeeded. After a certain
amount of failures we send a location update reject. (unsure which
cause)
best,
lynxis
Related Specs:
GSM 04.08 [1] Chapter 4.4 describing location update
GSM 04.08 [1] Chapter 11.2 Timers
GSM 04.08 [1] Chapter Annex G Reject Causes
[0] nitb.cfg: network: location updating reject cause
[1] ETSI TS 100 940
--
Alexander Couzens
mail: lynxis(a)fe80.eu
jabber: lynxis(a)fe80.eu
mobile: +4915123277221
gpg: 390D CF78 8BF9 AA50 4F8F F1E2 C29E 9DA6 A0DF 8604
Hi.
So far releases of Osmocom project were rather rare and without any schedule. It
would be nice to change that but to do that we've got to make the process of making a
release as smooth as possible.
The ticket which tracks this activity: https://projects.osmocom.org/issues/1861
What we have right now:
https://osmocom.org/projects/cellular-infrastructure/wiki/Make_a_new_release
What I've implemented: https://gerrit.osmocom.org/#/c/3130/
The TLDR:
we type "make REL=minor release" and get:
* signed and tagged commit
* automated version bump
* updated debian/changelog
Longer explanation:
That's implemented as separate makefile which is installed as part of libosmocore-dev
and can be re-used by other projects in few lines (see
https://gerrit.osmocom.org/#/c/3131/ for example).
It treats libraries separately from non-library projects (we don't have to clean up
TODO-RELEASE in the latter case). Also, it does not update LIBVERSION automatically
(see
https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info…"
for details) - I'm not quite sure how this can be automated.
Caveats:
- it does not push the committed result automatically - so far it's left as an
additional chance to inspect the changes before pushing them. Also I'm not sure if we
have to tweak our gerrit setup to allow for signed tags to go through and how will it
interact with auto-rebase.
- it does not replace human decision, it's still your job to adjust version
requirements for the libraries you use and properly bump LIBVERSION
- it enforces use of semantic versioning (see my previous email about semver and
http://semver.org/ for details)
Questions:
- does it make sense?
- what and, more importantly, how can we automate in addition to that?
The intention is to make release process easy enough so we could make releases more
frequently (maybe even have some schedule for it in a long run).
--
Max Suraev <msuraev(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
