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.
Hi all,
I just noticed that osmo-bts commit
6d117891c93da969e0ff8b293bef97c699490f2b is the last version that can be
brought up by the openBSC aka osmo-nitb.
Which makes me wonder now, should the openbsc / osmocom-nitb package
continue to be published to repositories?
Hi All,
I have scanned 3GPP documents for info on the GGSN IP network facing
side, IIUC how the GGSN responds there is "out of scope" - I'm
specifically wondering about sending ICMP host unreachable messages in
response to packets for IPs that are not currently active in the pool.
Sometimes it would happen where I was pinging an IP assigned to an MS
while looking at other things in the SGSN and PCU but in the meantime
the MS would cycle the PDP context and have a new IP.
For this and maybe other reasons I wrote a proof of concept, probably
not great code, but working, patch to have the GGSN send ICMP host
unreachable.
Do you think this is a desirable feature?
If so I would try to clean it up and submit to code review.
Also if in agreement, would it be worth making it switchable via a vty
param? I am thinking of where one might not want the IP space to be
probable, although I would assume that kind of thing is best left to the
local firewall implementation.
Patch here: http://git.osmocom.org/osmo-ggsn/?h=keith%2Ficmp
Thanks.
K.
Hi Andreas,
I pulled the new master, rebuilt my setup from source in a clean state and
it works as it should.
One more question though: is it possible to use the MNCC socket to connect
the NMT-450 network to 2G (via Osmo-BSC), or to SIP via LCR?
Thanks again!
Regards,
Csaba
Hi!
i'm very interested about GSUP <-> GSM MAP protocol conversion to
perform HLR interrogation. Do you suggest a suitable solution for this
problem? is there some related activity at OSMOCOM project?
Hi Andreas,
Fixed the patch. Yes there is a gap in the middle, that is why it is split
to two: 1..72 and 132..239 is the correct one and it uses a reverse
numbering like the Slovak or Czech networks. This is the reason the NMT
phones in Hungary was not compatible with any other country, and the phones
country settings were locked to Hungary only. For example in my MCR4800XL
the country cannot be set, yet if you read out the EPROM, it contains the
country settings for all country, but it is locked down to Hungary only.
Regards,
Csaba
<openbsc-request(a)lists.osmocom.org> ezt írta (időpont: 2020. okt. 28., Sze,
13:00):
> Send OpenBSC mailing list submissions to
> openbsc(a)lists.osmocom.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.osmocom.org/mailman/listinfo/openbsc
> or, via email, send a message with subject or body 'help' to
> openbsc-request(a)lists.osmocom.org
>
> You can reach the person managing the list at
> openbsc-owner(a)lists.osmocom.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of OpenBSC digest..."
>
>
> Today's Topics:
>
> 1. [PATCH] Adds country specific settings for Hungary. (Sipos Csaba)
> 2. Re: [PATCH] Adds country specific settings for Hungary.
> (Andreas Eversberg)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 27 Oct 2020 19:08:46 +0100
> From: Sipos Csaba <dchardware(a)gmail.com>
> To: "openbsc-request(a)lists.osmocom.org" <openbsc(a)lists.osmocom.org>
> Subject: [PATCH] Adds country specific settings for Hungary.
> Message-ID:
> <CALQr=E9WMDr_-KBwWdQAH=UgB88nd=
> ph2p1G2dOSG8F_CtY_Jg(a)mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> This is the final patch for Hungary specific settings for the
> osmocom-analog project.
>
> Tested against a locked Motorola MCR4800XL, it works on all channels and
> TAs.
>
> Please let me know if any more work needs to be done.
>
> Regards,
> Csaba
>
