Weird usage of gprs_ns_vty_init from gprs_bssgp_create

Harald Welte laforge at
Fri Jun 28 14:52:28 UTC 2013

Hi Andreas,

On Fri, Jun 28, 2013 at 04:00:56PM +0200, Andreas Eversberg wrote:
> the main problem is that the bssgp/ns instance is created at the time
> the bts (and the pcu) receives informations from bsc. the pcu cannot
> (yet) instantiate at startup time, the required informations for the
> instance are not yet present then. this means that the pcu.cfg cannot
> have any ns/nse vty command. i don't see a good solution right now.
> maybe it is possible to create only the bssgp/ns instance itself,
> without creating, listening, connecting the nsvc.

The existing libgb API should cater for that. You can very well just
call gprs_ns_instantiate() and gprs_ns_vty_init() at PCU startup time,
but call gprs_ns_nsip_listen() and gprs_ns_nsip_connect() at the time
you receive the configuration from the BTS via the PCU_IF_MSG_INFO_IND.

Wouldn't that solve the problem?

The fact that the VTY would parse statically configured 'nse' sections
in the config file should not be a problem, we can simply assume that
the user does not put any such config sections in the config file for
now.  If you're worried about saving them via 'write file / copy
running-config startup-config':  this is what the gprs_nsvc.persistent
member is for, isn't it?  Any non-persistent nsvc's will not be saved
via the VTY code.

Maybe I'm not understanding the problem yet, sorry.

- Harald Welte <laforge at> 
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

More information about the osmocom-net-gprs mailing list