Hi mister Harald,
thank you very much for your answer. I am an engineering student and I have started to work on my thesis.
I would like to perform a GPRS core network completely using virtual machine (virtual box based) and use it to prove that an operator can manage M2M traffic just using standard hardware, virtual machine and open source components (osmocom project ).
At this moment i deployed 4 virtual machine, one for each osmo component (osmoNITB, openGGSN, osmoSGSN) on the fourth VM I want to run the fakeBTS because I don't have a bts.
I would like to simulate it as if there are some M2M devices generate request(attach, pdp context for example).
When I try the communication between NITB and fakeBTS there are some error Messages related to RSL. Then there isn't communication between NITB-fakeBTS and SGSN-GGSN.
Do you detect any configuration error?
Thank you.
Best regard
Calo
-------- Original message -------- Subject: Re: GPRS core network simulation From: Harald Welte laforge@gnumonks.org To: calogero cannizzaro can_ni@hotmail.it CC: "openbsc@lists.osmocom.org" openbsc@lists.osmocom.org
Hi Calogero,
* what is the goal / use case of your simulation? * what exactly do you need to simulate? * what is the input/output of the simulation?
In general, the vaious Osmo-* implementations are not designed for simulation buy for actual network operation. So you will likely need to implement quite a lot in order to use it in a simulation context. The most important question is, that you need code that will behave as actual handsets on a network, and code to manage all those virtual handsets, tell them what they should be doing, etc.
Hi Calogero,
On Tue, Sep 09, 2014 at 02:19:13PM +0200, Calogero Cannizzaro wrote:
At this moment i deployed 4 virtual machine, one for each osmo component (osmoNITB, openGGSN, osmoSGSN) on the fourth VM I want to run the fakeBTS because I don't have a bts.
You wouldn't just need a virtual BTS, but also a virtual PCU and many virtual GPRS capable MS. Yes, this can be done, but it would be several man-months of software development even for an experienced developer who is already familiar with the specifications.
So unless the topic of developing software for such virtual BTS, PCU and GPRS-MS is the core of your thesis, I don't think this is a good idea.
Regards,
Hi mister Harald,
I give you more details about what I'm doing. I'm sorry for my inexperience.
I have built the following configuration (each component it's a virtual machine):
-------------------- | OsmoNITB | ------------------- | 192.168.30.2 | | | 192.168.60.1 192.168.10.2 192.168.10.1 ----------------- -------------------- ------------------ | FakeBTS | <---------------------> | OsmoSGSN | <-----------------> | OpenGGSN | ----> INTERNET ----------------- -------------------- ------------------ 192.168.20.1 192.168.20.2
OpenGGSN runs by using this configuration file:
# TAG: fg # Include this flag if process is to run in the foreground # #fg
# TAG: debug # Include this flag to include debug information. #debug
# TAG: conf # Configuration file to use. This file is the configuration file, # so changing this parameter in the configuration file does not make # sense. Use it on the command line instead.
# TAG: pidfile # File to store information about the process id of the program. # The program must have write access to this file/directory. #pidfile /var/run/ggsn.pid
# TAG: statedir # Directory to use for nonvolatile storage. # The program must have write access to this directory. #statedir /var/lib/ggsn/
# TAG: listen # Specifies the local IP address to listen to listen 192.168.10.1
# TAG: net # IP network address of external packet data network # Used to set up network interface. #net 192.168.0.0/24
# TAG: ipup # Script executed after network interface has been brought up. # Executed with the following parameters: <devicename> <ip address> #ipup /etc/ggsn/ip-up
# TAG: ipdown # Script executed after network interface has been taken down. # Executed with the following parameters: <devicename> <ip address> #ipdown /etc/ggsn/ip-down
# TAG: dynip # Dynamic IP address pool. # Used for allocation of dynamic IP address when address is not given # by HLR. # If this option is not given then the net option is used as a substitute. dynip 192.168.0.0/24
# TAG: statip # Use of this tag is currently UNSUPPORTED # Static IP address pool. # Used for allocation of static IP address by means of HLR. #statip 192.168.1.0/24
# TAG: pcodns1 # Protocol configuration option domain name system server 1. #pcodns1 0.0.0.0
# TAG: pcodns2 # Protocol configuration option domain name system server 2. #pcodns2 0.0.0.0
# TAG: timelimit # Exit after timelim OsmoSGSN runs by using this configuration file:
Osmocom SGSN configuration ! ! line vty no login ! sgsn gtp local-ip 192.168.10.2 ggsn 0 remote-ip 192.168.10.1 ggsn 0 gtp-version 1 ! ns timer tns-block 3 timer tns-block-retries 3 timer tns-reset 3 timer tns-reset-retries 3 timer tns-test 30 timer tns-alive 3 timer tns-alive-retries 10 encapsulation udp local-ip 192.168.0.128 encapsulation udp local-port 23000 encapsulation framerelay-gre enabled 0 ! bssgp
OsmoNITB runs by using the nanoBTS configuration file, configured for gprs support :
! OpenBSC configuration saved from vty ! ! password foo ! line vty no login ! e1_input e1_line 0 driver ipa network network country code 1 mobile network code 1 short name OpenBSC long name OpenBSC auth policy closed location updating reject cause 13 encryption a5 0 neci 1 rrlp mode none mm info 1 handover 0 handover window rxlev averaging 10 handover window rxqual averaging 1 handover window rxlev neighbor averaging 10 handover power budget interval 6 handover power budget hysteresis 3 handover maximum distance 9999 timer t3101 10 timer t3103 0 timer t3105 0 timer t3107 0 timer t3109 4 timer t3111 0 timer t3113 60 timer t3115 0 timer t3117 0 timer t3119 0 timer t3141 0 bts 0 type nanobts band DCS1800 cell_identity 0 location_area_code 1 training_sequence_code 7 base_station_id_code 63 ms max power 15 cell reselection hysteresis 4 rxlev access min 0 channel allocator ascending rach tx integer 9 rach max transmission 7 ip.access unit_id 1801 0 oml ip.access stream_id 255 line 0 gprs mode gprs gprs routing area 0 gprs cell bvci 2 gprs nsei 101 gprs nsvc 0 nsvci 101 gprs nsvc 0 local udp port 23000 gprs nsvc 0 remote udp port 23000 gprs nsvc 0 remote ip 192.168.20.2 trx 0 rf_locked 0 arfcn 514 nominal power 23 max_power_red 20 rsl e1 tei 0 timeslot 0 phys_chan_config CCCH+SDCCH4 timeslot 1 phys_chan_config SDCCH8 timeslot 2 phys_chan_config TCH/F timeslot 3 phys_chan_config TCH/F timeslot 4 phys_chan_config TCH/F timeslot 5 phys_chan_config TCH/F timeslot 6 phys_chan_config TCH/F timeslot 7 phys_chan_config PDCH
Finally, according to this guide: http://openbsc.osmocom.org/trac/wiki/simulation , I installed smalltalk interpreter on fakeBTS VM, and then i tried to run the Smalltalk script to request a channel. This is what happens:
OsmoSGSN and OpenGGSN run but there isn't messages exchange.
OsmoNITB runs and receive messages from fakeBTS but I read this error: <0004> abis_rsl.c:2050 unknown RSL message discriminator 0x01
<0019> input/ipaccess.c:458 Bad signalling message,sign_link returned error
Furthermore there isn't communication toward OsmoSGSN.
I would like to achieve a simple communication among this components. For example ,running a script on fakeBTS to generate a PDP context request or attach request, I would like to see the request toward OsmoNITB, OsmoSGSN and finally OpenGGSN, and the response go back.
My questions are: 1. Is the network configuration correct? 2. Are the configuration file correct? 3. How can I fix the RSL error message?t 4. Does a script to generate a PDP context request or attach request exist in FakeBTS package? If not, do you think that it's possible to write it in a short time?
Best regards and thanks for help.
Calogero
Date: Thu, 11 Sep 2014 12:46:07 +0800 From: laforge@gnumonks.org To: can_ni@hotmail.it Subject: Re: GPRS core network simulation CC: openbsc@lists.osmocom.org
Hi Calogero,
On Tue, Sep 09, 2014 at 02:19:13PM +0200, Calogero Cannizzaro wrote:
At this moment i deployed 4 virtual machine, one for each osmo component (osmoNITB, openGGSN, osmoSGSN) on the fourth VM I want to run the fakeBTS because I don't have a bts.
You wouldn't just need a virtual BTS, but also a virtual PCU and many virtual GPRS capable MS. Yes, this can be done, but it would be several man-months of software development even for an experienced developer who is already familiar with the specifications.
So unless the topic of developing software for such virtual BTS, PCU and GPRS-MS is the core of your thesis, I don't think this is a good idea.
Regards,
- Harald Welte laforge@gnumonks.org http://laforge.gnumonks.org/
============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)