> 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.
On Tue, Jun 28, 2016 at 10:05:28AM +0200, Harald Welte wrote:
> [translated from german]
> is it certain that we switch a channel to PDCH only when
> gprs mode != none?
A TS can be GSM_PCHAN_TCH_F_PDCH; those are the only ones for which we
send a PDCH ACT message.
We send a PDCH ACT message
- during init (CHANNEL OML's state changed to enabled -> send PDCH ACT),
- and upon channel release ack when pchan == GSM_PCHAN_TCH_F_PDCH.
So the question is, when we receive a channel release ack, could that be
the PDCH release and we switch PDCH right back on by accident? No, because
we only receive a chan rel ack when the *TCH/F* is being released.
That is because the PDCH release is initiated "internally" from the PDCH
DEACT, and thus this condition in common/rsl.c rsl_tx_rf_rel_ack() catches
on, which existed before dyn PDCH:
if (lchan->rel_act_kind != LCHAN_REL_ACT_RSL) {
LOGP(DRSL, LOGL_NOTICE, "%s not sending REL ACK\n",
gsm_lchan_name(lchan));
return 0;
}
In rsl_rx_rf_chan_rel() the rel_act_kind is set to LCHAN_REL_ACT_RSL, but
not in the rsl_rx_dyn_pdch().
This is analogous to the ip.access way -- the ip.access nanobts replies to
a PDCH DEACT with a PDCH DEACT ACK and doesn't send a separate channel
release ack.
Maybe we could set rel_act_kind to some new LCHAN_REL_ACT_IPAC_DYN_PDCH
for clarity? (But we shouldn't actually send a release ack, to stay
compatible.)
Even though it works as-is, we should indeed add another flag check:
- We do check the flags that no ACT/DEACT is already pending;
- And we do send a PDCH DEACT only if ts->flags & TS_F_PDCH_ACTIVE;
- But we would send a PDCH ACT despite ts->flags & TS_F_PDCH_ACTIVE.
This should never happen, but it would make sense to ensure that.
~Neels
Hi,
My name is Brackley Cassinga Form DRC, we run a community network called
pamoja net where we offer gsm services using osmocom open source software
and OC Base station.
Recently I have tried to install another base station as the same installed
but I could not find any resource guiding through all the steps to take to
run NIB on a base station.
I'm currently running Ubuntu and I will appreciate if you could guide me on
the installation of BSC,hlr,MSC , in order to run a basic gsm network.
Thank you. Regards
--
*Ir Brackley heshima Casinga **Pacifique*
*CEO and Founder of kwanzatechnologie*
KwanzaTechnologies ,GlobalElectronics
+243977265291 | +243977265291 | Pcassinga(a)gmail.com/
brackley(a)ensemblepourladifference.org
www.kwantechnologies.jimdosite.com <http://www.kwantechnologies.com/> |
Skype: Brackley cassinga <https://webapp.wisestamp.com/#>
Av Semliki N 43
Hello Pierre,
> Hi, could you share your gist that you have posted earlier in the
> following url?
>
> https://gist.github.com/efistokl/b95538772e54e5edb7765021c2b5a745#22-config…
I think the README.md of the repo
https://github.com/Pentonet/pentonet-genieacs-package has the same
contents as the gist you mentioned used to have. (I've just made the
repo public)
Also, the repository contains a package I used to set up my nano3g. I
didn't document it at all though.
Also, I think in the gist I didn't include these two fields:
Device.Services.FAPService.1.CellConfig.UMTS.RAN.X_000295_DataOnFACHEnable
= false (xsd:boolean)
Device.Services.FAPService.1.CellConfig.UMTS.RAN.X_000295_FdEnabled =
false (xsd:boolean)
They are important for PS to work properly (as said by ip.access support).
> I am trying to set up my nano3Gs once again and I remember reading this
> awesome guide before, but when I visited the page today, sadly it was
> not available anymore.
Thanks, I am glad it was useful.
Kind regards,
Mykola
Dear Osmocom community,
I'd like to share this with you, as I believe not many have read the
book "GSM and UMTS; The Creation of Global Mobile Communications" by
Friedhelm Hillebrand (who by the way just received the Order of Merit of
the Federal Republic of Germany for his substantial contributions to
mobile communications).
The document (and some others on the included CD-ROM that comes with the
book) reminds me to the much more widely known "Aprils Fool RFCs"
within the IETF. It's a pity that ETSI - unlike IETF - didn't go through
with it and hence those documents were never officially published, so
that today only some fax scans seem to exist.
Enjoy!
--
- Harald Welte <hwelte(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
Hello GSM network side community,
I am doing some research in preparation for possibly setting up my own
GSM/2G BTS in my rural town of Middle-of-Nowhere, California to serve
as a replacement for our current GSM/2G service provided by T-Mobile
USA, a contingency plan to be activated if and when the evil corporate
owners of T-Mobile shut down their 2G service. I haven't bought my
BTS hardware yet - I am still doing research and comparing options,
and I also need to do some other preparatory work without which the
BTS won't be of any use.
I have a question about GSM BTS Tx power levels. Some BTS vendors
advertise models with up to 10 W power output, but I don't understand
how such high power output from a BTS can be useful when MS power
output in the other direction is limited to 1 W in high bands or to
2 W in low bands. The whole point of a BTS is to provide service to
subscribers, and in order for a subscriber to be able to make a call
or to engage in a text conversation, there has to be two-way
communication between the BTS and the MS: the MS needs to hear the
downlink signal from the BTS, and the BTS needs to hear the uplink
signal sent by the MS. If you have a BTS that puts out 10 W on the
downlink, wouldn't the effective range be limited at the point where
the BTS can no longer receive the 1 W (high bands) or 2 W (low bands)
uplink put out by the MS? And if the range limit is set by the Tx
power limit of standard GSM MS units, what is the point of having the
BTS put out more power on the downlink than the very same 1 W or 2 W
limit that applies to uplink Tx power?
I can only reason that I must be missing something big here, as those
BTS manufacturers who offer models with 10 W output surely make such
hardware for some very valid use cases - but I would like to understand
it better. Can someone perhaps explain this mystery to me?
TIA,
Mychaela
Dear openBSC society,
Would you be so kind to advise me on the following:
I desire (dramatically want very much) to learn / understand Osmocom projects.
I am a beginner in programming and i try to understand / learn C files that the project is build of.
As an example i tried to learn / understand for example an Osmocom message buffer — msgb.h file.
But immediately faced some syntax difficulties:
This is the extract of msgb.h file:
struct msgb {
struct llist_head list; /*!< \brief linked list header */
/* Part of which TRX logical channel we were received / transmitted */
/* FIXME: move them into the control buffer */
union {
void *dst; /*!< \brief reference of origin/destination */
struct gsm_bts_trx *trx;
};
As it can be seen a structure «msgb» has as one of its components another structure — «gsm_bts_trx»
But in whole Osmocom BB project files i could not find definition / description of struct «gsm_bts_trx».
Would you kindly advise me please how to see which components / constituents / elements are in this gsm_bts_trx structure?
From which components is struct gsm_bts_trx build of?
Thank you so much for your kind advise.
--
Mario Lucas
Hello all!
I'm still trying to bring onAir any of BTS in lab.
Today we were trying with Ericsson RBS-2206. We limited hardware to the
minimal possible setup containing:
DXU-21
dTRU-1800
CDU-G 1800
And we created IDB with 1 cell 1TX 2RX
After it we tried to use default config from master branch initially
created for RBS-2308.
It worked pretty fine except RF Power which was configured as 41dBm and 41
- 12 = 29 dBm. Value 29 was not acceptable for our RBS.
I checked with Ericsson BSC Doc and found that our RBS2206 has max RF
output 47dBm for DCS1800. (btw, RBS2308 has only 34dBm max output according
to the same document, maybe config needs to be corrected)
After setting 47dBm to config, TX-0 was configured correctly and
Operational led was on.
The main problem we are faced now is unavailability to perform
"Enable"action on TX and RX objects and all next steps are not successful
too.
After getting logs from RBS (all files are attached) I see that TX and RX
enabling fails with line:
[20-11-03 11:51:27.264] 0\RC_HWU_TX hwu_tx_state.c:223 TRACED:TX Enable
FAILED!, RCFW_ATC_State NOT Synchronized
Looks like internal oscillator is not ready. So, the question is how to
make internal oscillator synchronized? Could it be an E1 Sync stability
issue caused by Digium cards? I remember we discussed it on earlier steps
of bringing up OSMO-BSC.
Now I have just 2 ideas what to do:
1. Set Digium card to get Sync from RBS. Now Digium is configured for
Internal clocking and acts as master. Maybe in case when both sides will be
configured to get sync from E1 it will decrease difference between internal
clock of RBS and E1 and RBS will get Synced state.
2. Theoretically I can try to use Nokia DX200 BSC as a clock master for
Digium and deliver sync to RBS from Digium. I'm not sure if timing accuracy
is the same for Nokia and Ericsson HW.
One more question is where can I find some info about timing accuracy for
BTS and any possible way to check it on the existing E1 line?
Thank you
Babanov Ivan
Hello
I tried to buy a sysmoISIM-SJA2 but it was not available to my region, so I acquired a Chinese writable sim card with adm keys (https://www.aliexpress.com/item/32813645415.html). With their software I can read PIN, PUK, ADM, ISMI, PLMN, EHPLMN, etc exactly as on the image on the link mentioned.
pcsc_scan detected it (even with a weird name) from a Chinese brand manufacture using https://github.com/LudovicRousseau/pcsc-tools/blob/master/smartcard_list.txt.
I tried pySim-read and it failed on the end saying that OpenCellsSim' object has no attribute 'read_ehplmn'. I'm sharing the full output if anyone is interested. It's weird because it fails to read ISMI and ICCID for example and other fields. I started recently studying this area, I took a look at pySim code and looks like that it's based on size of data to detect if it's OpenCells or not (which I believe is not my case). Is there a easy way to know if my Chinese card is OpenCells or whatever they are?
$ ./pySim-read.py -p 0
Using PC/SC reader interface
Reading ...
Autodetected card type: OpenCells-SIM
ICCID:
IMSI: None
GID1: ffffffff
GID2: ffffffff
SMSP: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
SPN: CMCC
Display HPLMN: False
Display OPLMN: False
PLMNsel: 32d00032d01034f06045f08032f32212f020ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
PLMNwAcT:
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
OPLMNwAcT:
32d0004000 # MCC: 460 MNC: 000 AcT: E-UTRAN
32d0008000 # MCC: 460 MNC: 000 AcT: UTRAN
32d0000080 # MCC: 460 MNC: 000 AcT: GSM
...
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
HPLMNAcT:
32d0004000 # MCC: 460 MNC: 000 AcT: E-UTRAN
32d0008000 # MCC: 460 MNC: 000 AcT: UTRAN
32d0000080 # MCC: 460 MNC: 000 AcT: GSM
ACC: ffff
MSISDN: Not available
Administrative data: 00000002
MS operation mode: normal operation
Ciphering Indicator: disabled
SIM Service Table: ff33ffff00003f033000f0c3
Service 1 - CHV1 disable function
Service 2 - Abbreviated Dialling Numbers (ADN)
Service 3 - Fixed Dialling Numbers (FDN)
Service 4 - Short Message Storage (SMS)
Service 5 - Advice of Charge (AoC)
Service 6 - Capability Configuration Parameters (CCP)
Service 7 - PLMN selector
Service 8 - RFU
Service 9 - MSISDN
Service 10 - Extension1
Service 13 - Last Number Dialled (LND)
Service 14 - Cell Broadcast Message Identifier
Service 17 - Service Provider Name
Service 18 - Service Dialling Numbers (SDN)
Service 19 - Extension3
Service 20 - RFU
Service 21 - VGCS Group Identifier List (EFVGCS and EFVGCSS)
Service 22 - VBS Group Identifier List (EFVBS and EFVBSS)
Service 23 - enhanced Multi-Level Precedence and Pre-emption Service
Service 24 - Automatic Answer for eMLPP
Service 25 - Data download via SMS-CB
Service 26 - Data download via SMS-PP
Service 27 - Menu selection
Service 28 - Call control
Service 29 - Proactive SIM
Service 30 - Cell Broadcast Message Identifier Ranges
Service 31 - Barred Dialling Numbers (BDN)
Service 32 - Extension4
Service 49 - MExE
Service 50 - Reserved and shall be ignored
Service 51 - PLMN Network Name
Service 52 - Operator PLMN List
Service 53 - Mailbox Dialling Numbers
Service 54 - Message Waiting Indication Status
Service 57 - Multimedia Messaging Service (MMS)
Service 58 - Extension 8
Traceback (most recent call last):
File "./pySim-read.py", line 255, in <module>
(res, sw) = card.read_ehplmn()
AttributeError: 'OpenCellsSim' object has no attribute 'read_ehplmn'
As I can't buy the sysmoISIM-SJA2 where I live, I searched for other sellers. I found this one (https://www.aliexpress.com/i/32272726951.html) where an user wrote
"+ Devices work. + Use GRSIMWrite to program them initially. After you do this, you will know PIN-ADM so then pysim will work. - PsiWords could spend a little time pointing people at correct software to program cards. That would be, as they like to say, much more professional! (Especially if they want repeat business!)
21 Aug 2018 16:43".
I'm curious if this card sold by other user just have a different encoding / format to read/write data from mine, because the PIN + ADM keys I also can obtain from their software, however, since my card is in another format I don't believe that I will have success to write it. Am I wrong?
I saw the list of supported SIM cards and some of them are very limited. Someone already acquired a SIM card with great compatibility with pysim from China? I searched for supersim, fakemagicsim and some combinations and no success.
fakemagicsim
supersim
magicsim
grcardsim
sysmosim-gr1
sysmoSIM-GR2
sysmoUSIM-GR1
sysmoUSIM-SJS1
Fairwaves-SIM
OpenCells-SIM
Wavemobile-SIM
sysmoISIM-SJA2
Any help or advise is very welcome.
--
Sent with https://mailfence.com
Secure and private email
Hello there!
The question out of curiosity. Hard to not notice quite a few of
projects written in Smalltalk.
Why was cellular network implementation in Smalltalk abandoned?
Or was everything in C initially and you just tried out Smalltalk as a
possible alternative?
What was your thinking back then?
Interested to know some history.
Thanks a lot!
P.S. of course, I see some stuff in Erlang as well, but it has an
awesome Diameter support which kind of answers a similar question but
related to Erlang.
