> I don't understand. This callback will be called with data you need to
write
> to the network. In case of MTP Level3 you will need to wrap that around
the
> msgb you got.
I means: is the interaction with mtp3 layer implemented (is sending sccp
data by mtp3 implemented by the library?)?
Also, what about the reception of data from mtp3 layer. is that implemented
in the sccp lib.
I am asking these questions because I see the code of mtp3 in the lib but no
significant call is present in the sccp part of the lib.
Thank you for your help.
I have some questions:
1) When I start bsc_hack bsc_init.c first establishes OML link and
initializes the bts then it establishes RSL link and bts starts
broadcasting. However, it takes so much time to start the bts. Instead of
this I want to do the following: it establishes OML link at the beginning
and only once, then when i want to start broadcasting it establishes just
the RSL link and bts will start faster since i don't have to wait for OML
link. What should be done for this?
2) If i send one or two word messages from telnet interface it is okay. But
if i send a longer message the phone could't receive the end of the message
correctly(last words may be incomplete). Did any one encounter with this
problem? What is wrong with me?
3) Could I send SMS in which extension of the sender is text not integer.
For example, i want to send an information SMS that this is a test network.
For this purpose i want to send an SMS from 'OpenBSC'. I set the extension
of the first subscriber in database as text and tried to send the SMS but
SMS wasn't delivered. What should i do?
4) Can i add SMS externally to SMS table of database?
Thanks.
Jason
Hi Peter and others,
it seems like the situation regarding the GSM network at the Camp is
starting to become clearer every day.
I am still arguing that two relatively large BTS with circular antennas
are a good idea. Therefore, I have now applied for a test license with
the regulatory authority with the following parameters:
* six GSM 1800 ARFCN
* two antennas, circular, 18 meters above ground
* 5W output power on each ARFCN. I know one of my customers in Germany
has once managed to get a license for 5W, so I thought it is a good
bet we should get the same. It should be more than sufficient to
cover the camp.
* from August 2nd through August 15th, i.e. we have time for build-up
and can also run it one more day during shutdown of the camp
I should be receiving "Motorola Horizon Macro" BTSs with 3 to 6 TRX each
soon. They are able to drive something like >= 20W output power, way
more than we need. The only problem with those BTS is: We will need to
add the Motorola A-bis dialect to OpenBSC before the Camp, which could
be a tough task depending on how far they are off the standard A-bis
as specified in 08.58 and 12.21.
If we cannot make those BTS work, our options are somewhat limited.
1) nanoBTS based
The nanoBTS are 200mW only, so we would need a booster. Those cost
about 1000 EUR for 6W downlink power + 18dB uplink LNA. Who is going
to fund that? Also, we would need a combiner/splitter to run
something like a 3-TRX setup.
2) Ericsson RBS
I should have two RBS 2308 (4TRX each) soon, but both of them are GSM
1900. It is unlikely that we ge a license, and a lot of phones probably
don't support it. So unless they can somehow be converted to 1800
MHz units, they are not a good fit either :/
3) Siemens BS-11
All of them are GSM 900. No way to get a license in Germany, sorry.
So we basically _have to_ make the Motorola Horizon work...
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)
Hello
Our goal was to send status sms via the vty interface. But all of our
sms were cropped. In contrast sms from one MS to another MS are
displayed correctly (despite the fact, that the text at the database
contains several '@' at the end / the user_data contains several
zero-octets). Therefore i have inspect the code and found several bugs.
The main problem is that the "user_data_len" is not correctly used. As
per GSM 03.40, 9.2.3.16 TP‑User‑Data‑Length (TP‑UDL):
"If the TP‑User‑Data is coded using the GSM 7 bit default alphabet, the
TP‑User‑Data‑Length field gives an integer representation of the number
of septets within the TP‑User‑Data field to follow."
Currently the "user_data_len" contains the number of octets (returned
from gsm_7bit_encode(...) at gsm_utils.c (libosmocore)).
The big problem here is that this information is not unique, e.g.:
1.) 46 non-extension characters + 1 extension character => (46 * 7 bit +
(1 * (2 * 7 bit))) / 8 bit = 42 octets
2.) 47 non-extension characters => (47 * 7 bit) / 8 bit = 41,125 = 42 octets
3.) 48 non-extension characters => (48 * 7 bit) / 8 bit = 42 octects
But the MS has to know the correct "user_data_len" to decode the correct
number of characters.
For this reason i updated the gsm_7bit_encode() function to return the
correct number of septets. However sometimes it is needed to know the
correct number of octets (e.g. at gsm_04_11.c: gsm340_gen_tpdu(...)) =>
i added a function to gsm_utils.c named:
uint8_t get_octet_len(const uint8_t sept_len)
I have also fixed the problem, that the sms are wrongly stored /
displayed on the database. But the solution on the function
*sms_from_result(...) (at db.c) is not really "beautiful". This is
because there exists no "user_data_len" field at the database. To store
the right value for "user_data_len" (which is further needed) i have to
get the length from the "text" field. Unfortunately this is not enough.
If the text contains extension characters like {[]} etc. then the
"user_data_len" has to be bigger because these characters needs two
septets. Therefore i use a switch statement so search for these
characters. A better solution for that is to store the right
"user_data_len" to the database (on the encoding / decoding procedure).
But i don't know if this is a suitable solution for all of you (because
you have to change your database structure etc.).
Best Regards
Dennis Wehrle
Hi all,
so far we do not have any statement about the licensing of the content on
our wiki. This means the default copyright rules apply: All the content is
copyrighted, and nobody has any rgiht to reproduce it at all.
I would like to propose an official license for the content in the wiki:
Create Commons CC-BY-SA. The alternative would be to go for CC-BY-NC-SA,
disallowing commercial use of the content.
I'm not certain if NC is really what we want. After all, even somebody
using OpenBSC in a commercial environment should be able to make copies
of the reference documentation we have available - as long as he will
releas the result again (which the SA part already covers).
If the major contributors to the wiki would agree to a license, I would
update the wiki accordingly.
Thanks,
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)
From: Pablo Neira Ayuso <pablo(a)gnumonks.org>
Hi!
With these patches, libosmocore, libosmo-sccp, openbsc and osmo-tetra
does not use anymore our own copy of talloc and they rely on the
standalone library that is provided by major distributors.
The osmocom-bb part is still missing, my idea is to include a copy
of libtalloc in the tree in the shared/ directory via rsync. This
patch will follow later since we can still rely on the outdated
copy of libosmocore.
Please, apply.
Hi!
As more and more code is moving into libraries (like I just did with the
LAPDm code, and like pablo is working on with libosmo-abis), we needed a
solution how to allocate and use the LOGP subsystem constants like DRSL,
DRR, ... from within libraries.
The existing logging code wasn't really prepared for that. I've now
come um with a hack to extend it while preserving compatibility to
applications:
* we use negative numbers starting from -1 for library-internal
subsystems
* those numbers get converted to a positive index into the various
arrays at run-time. So -1 ends up one entry higher in the array
than the last application-providede log category/subsystem.
As part of this change, the array allocations are now dynamic, i.e there
is no maximum limit for the number of log categories that an application
can register with the core.
Only for libraries (even outside libosmocore), we have compile-time
registration, i.e. the 'struct log_info_cat' and the D* constant need to
be defined inside libosmocore. I think this is an acceptable
compromise.
Furthermore, if LOGP()/DEBUGP() ever see a subsystem number that it
doesn't know, it will assign it to the new 'DLGLOBAL' (Debug Library
GLOBAL) category, i.e. there cna be no array overflows.
This ensures that even an external library using a 'newer' D* constant
will not crash or otherwise fail, it will simply log in a slightly
different way.
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 everybody!
I need to replicate in my private network the functionalities of an SGSN and
a GGSN for academic purpose. I see the openGGSN project and I understand
that it's composed by two components: sgsnemu and ggsn.
What I want to ask to you is if I could test all the PDP Context activation
process with these two components and how.
This is the real (very semplified) process:
Mobile Phone ---> SGSN ---> GGSN ---> SGSN ---> Mobile Phone
(for a full description of the process see
here<http://www.eventhelix.com/RealtimeMantra/Telecom/gprs_attach_pdp_sequence_d…>
)
My suspicion, tell me if I'm wrong, is that sgsnemu component allow to test
only this part of the complete process:
SGSN ---> GGSN ---> SGSN
(simulating the mobile terminal request but not really accepting it from an
external module/device). Is it right?
How could I test all the process? Consider that I could use a linux pc
instead of a mobile phone.
Thank you very much!!!
--
Guido Cilia
Web: http://www.guidocilia.it
E-Mail: guidocx84(a)gmail.com
Skype: guidocx84
Hi all,
it seems like supporting the Motorola BTS from OpenBSC is a really big
challenge. Not only are there problems regarding an unknown
configuration database format (see
http://laforge.gnumonks.org/weblog/2011/06/18/)
Dieter has found the following excellent document, which in Chapter 5
describes the architecture of the Motorola specific changes to A-bis:
http://read.pudn.com/downloads61/ebook/212957/SYS01.pdf
Judging from the document:
* there is an unknown 'motorola executive header' in front of RSL
* many RSL standard messages have been replaced by proprietary ones
* they use a mixture of 08.08 (A) and 08.58 (A-bis) information elements
* many features normally found in the BSC are implemented in the BTS,
e.g. the entire CHAN RQD / RSL CHAN ACT / IMM ASS CMD sequence is
done fully inside the BTS.
As a result, I think it will be a quite complex project to support those
BTSs from OpenBSC. It's not just a matter of adding some small
vendor-specific OML messages like with Siemens, Ericsson and ip.access.
While it might still be interesting, I think it's unrealistic to assume
this would happen ahead of the camp [unless somebody finds a compatible
Motorola BSC that they can borrow us for analysis + protocol tracing].
Thus, the focus for the 2011 CCC Camp is now back to ip.access. The
main issues we will be facing is on the RF side, i.e.
* RF PA for the TX side
* combining the PA outputs to be transmitted on one antenna
* filter + LNA for Rx side
* splitting the Rx signal
As indicated previously, I would love to see something like two BTS
with three TRX each.
If we'd recycle the duplexer/combiner blocks from the Motorola BTS, we
could do something like three sites with 2 TRX each. (as they can only
combine two TRX).
We _might_ also be able to re-cycle the TX PA from the Motorola CTUs, at
least on the RF side it would be pretty easy to drive them from a
nanoBTS rather than its internal source (as there's a connector).
The bigger question is how do we get the controller logic of the PA into
a state that the PA is actually enabled and active...
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 zecke and others,
I may have found a cause of one of the problems that we've been
experiencing in nanoBTS bring-up, at least at some point in the past.
The problem could be observed/described as: During the first OML
connect of the nanoBTS, OpenBSC fails to bring it up completely. Second
and successive connects worked fine.
What I have just noticed is that we never re-set the NM state
information for the 12.21 MOs inside OpenBSC. This means, if the A-bis
link is lost, the old state information continues to exist.
I guess it would be cleaner to simply re-set all the nm_state strucures
that are part of the 'struct gsm_bts', gsm_bts_trx, etc. when the A-bis
link is lost.
As I'm working in this area right now anyway, I intend to produce a
patch addressing the issue.
But now that I think more about it: I guess it is unrelated to the old
problem, as a typical work-around was to re-start OpenBSC, at which time
all state is re-set again.
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)
