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 at gnumonks.org
> To: can_ni at hotmail.it
> Subject: Re: GPRS core network simulation
> CC: openbsc at 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 at gnumonks.org> http://laforge.gnumonks.org/
> ============================================================================
> "Privacy in residential applications is a desirable marketing option."
> (ETSI EN 300 175-7 Ch. A6)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20140911/9f674d79/attachment-0001.html>