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)