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(a)gnumonks.org
To: can_ni(a)hotmail.it
Subject: Re: GPRS core network simulation
CC: openbsc(a)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(a)gnumonks.org>
http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)