Code to implement handover control logic. A yet-to-be-implemented
handover algorithm will call bsc_handover_start(old_lchan, new_bts)
to start the handover process.
This introduces the signals S_LCHAN_ACTIVATE_{ACK,NACK} and
S_LCAN_HANDOVER_{FAIL,COMPL,DETECT} as well as code that actually issues
those signals. The signals are relevant for a yet-to-be-written handover
control logic.
This is needed by a yet-to-be-implemented handover algorithm, after
it has allocated a new lchan for the MS. Also missing: handling
the actual HANDOVER COMPLETE / FAIL messages in response.
This patch extends struct gsm_meas_rep into a complete structure containing all
information from both uplink and downlink measurement results/reports.
This is a first step to provide this complete measurement data as a C structure
into a to-be-implemented handover decision algorithm.
- Make sure that on runtime the Radio Carrier can be
locked and unlocked. The vty code calls into the
Abis NM to lock/unlock the channel and the state is
stored there.
- Make sure that on start the Radio Carries remains
offline and we are not starting it. On start the
radio carrier is either locked or unlocked. This means
the RSL will not connect until the RF is unlocked. It
will connect then. To see RSL bringup failures one
needs to parse the RSL nack message.
- When the TRX is locked on startup the RSL link will
only be established after it will be unlocked.
The python script is a simple call-agent driving the
client. Currently it is sending a AuditEndpoint message
and is printing the result.
The bsc_mgcp.c is a standalone process that will implement
a MGCP Gateway for the MSC. On call handling the Call-Agent
will ask the Gateway to "CreateConnection" and then this
gateway needs to communicate with OpenBSC.
Currently CreateConnection,ModifiyConnection,DeleteConnection
and Endpoint auditing is implemented.
[mgcp] Send RSIP on start and on first receive of any message
Ignore the first request and send a RSIP. We do that because
we might tunnel UDP through some other things and have no direct
way to connect to the call-agent.
Also the transaction is not checked and we ignore the response
from the call-agent, actually we print the '200 ' or any other
value as unhandled...
[mgcp] Print the MGCP command next to the response code
This allows to see which commands were sent by the server
mgcp: Terminate it with a new line
[mgcp] Make number of endpoints static...
For now this is fixed to the number of endpoints as of the GSM
specification...
[mgcp] The endpoint names seem to be base 16... use strtoul to parse
Use strtoul to parse the base 16 number from the mgw string.
[mgcp] Log the endpoints as hex numbers...
[mgcp] Only send the RSIP on the first incoming message..
Remove call_agent option (also remove the number from the getopt
call).
[mgcp] Start couting at 1 for the mgcp
[mgcp] Slight attempt to improve the grammar of the strings
[mgcp] Share validation routines between DLCX and MDCX
[mgcp] Remove help for dead config options
[mgcp] Specify a different IN addr in the SDP records
In case of NAT traversal be able to listen on a given
interface (like 127.0.0.1) but claim to receive data
at the beginning of the tunnel.
[mgcp] Fix the static copy of the SDP file
WIP verify out factoring broken..
[mgcp] Introduce VTY to the mgcp for config file parsing...
Parse the MGCP config file via the VTY framework.
[mgcp] Handle SDP parameters through VTY..
Currently the payload type, name and rate can be specified
in the config file.
[mgcp] Add an option to bind all rtp ports early
This can be useful for testing and in deployment to make sure
no runtime resource limit can be hit.
[mgcp] Add some API doc comment
[mgcp] Convert the packets of the example server to ascii
This will allow to easily patch the call id... to run the
server in a loop and make it work with the mediagateway
[mgcp] Assign CI_UNUSED... to be more obvious...
[mgcp] Use DEBUG and not DEBUGPC and specially not printf
Improve the logging a bit in the mgcp
[mgcp] Change the fake server to change the call id
This assume the call-agent will just increment the id
as well.... this is true for our implementation
[mgcp] Generate the transaction id dynamically..
This way wireshark will be more happy about it...
[mgcp] Recognize responses from the network..
This is just recognizing the response code and
then is doing nothing with it. Also change the
script to generate response messages...
[mgcp] Improve debug messages for CRCX/MDCX..
Log on which ports the media gateway is listening
and where the other (server) gateway is located
Currently this will send a dummy inactivity test message,
there is currently no parsing or API to receive the messages.
The sequencing and credit entries are empty as sequencing
is currently not used at all.
The test is currently limited to send the message and see
if the application is crashing or not.
include/sccp/sccp_types.h contain Q.713 and GSM definitions
include/sccp/sccp.h is the application interface resembling
the esentials of the UNIX socket interface.
src/sccp.c is the actual implementation of SCCP featuring
connection and UDT1 support.
tests/sccp/sccp.c is testing connection creation and formating
of the SCCP messages used by the A-interface. And
it contains a simple fuzzing test to test the
robustnes of the implementation.
Both GSM 04.08 RR and GSM 08.58 RSL need the multirate config
in the channel modify. Place the config in the lchan, change
the gsm48 methods to not take the argument, change the RSL
implementation to make use of it with the right IE.
The other code should use the t(l)v_put routines as well but
were left untouched for now.
IPA is naming these functions CRCX, MDCX, DLCX to follow
the naming of the MediaGatewayControlProtocol. Change the
code to go from BIND to CRCX (create connection) and from
CONNECT to MDCX (modify connection).
Connect indicates that it is only possible to call it once
while it is possible to call it more than once to modify
the audio parmaters and such. So the IPA terminology is
making a bit more sense here (now that we know it).
E.g. to analyze the subscr_get/subscr_put behavior one can place
the generate_backtrace into the functions, recompile and then filter
the output with contrib/bt.py to get the function name, file and line.
On channel mode modify and assignment command when using
the a multirate code the multirate configuration must be
present in the packet.
Add a parameter and add a warning when using it in a
broken way.
Allow to handle the channel requested differently based
on the NECI value for the "paging any" case. This will allow
to open a TCH/H, TCH/F depending on the neci mode.
This allows the administrator to use the vty interface to issue a silent
call to a given subscriber by using
"subscriber extension XXXX silent call start"
and stopping that silent call with
"subscriber extension XXXX silent call stop"
This is confirmed by looking at the source of their dissector.
The length can go up to 273 bytes apparently (again, according
to the source of their dissector).
Keep track of which SAPIs have been established either by the
BTS (from the MS) or by us. This can be used by the on-waves
BSC code to figure out if a new request should be made.
Be able to send RR CHANNEL MODIFY from the BSC/MSC code
as well. Move the method that knows about the IPAccess RTP
and issues the "bind" to the utils tool
Add code to generate an assignment command for a given lchan. It
is expected that the lchan is modified already and the mode will
be picked up from their. Currently only the mandantory items
are supported.
- Improved handling of extension-number string (as per review)
- Guard against a buffer-overflow if mobile sends a too-long USSD
- declare some function-parameters const
- fix gsm_ts_name function to display the right BTS number (bts->nr rather than bts->bts_nr)
This patch removes the need of static global variables and introduces a new,
caller-allocated 'struct ussd_request' that needs to be passed to the various
functions.
This is needed when you need to manually parse TLV blocks
that don't follow the logic supported by tlv_parse but you
still want to rely on working code and not fiddle with details.
If we have a dynamic TCH/F / PDCH channel configuration, then
we can either ACTIVATE CHANNEL it for a TCH/F, or we need to send
this vendor-specific PDCH ACTIVATE command to use it as a PDCH.
As opposed to a fixed configuration, this allows an intelligent
BSC channel allocator to use otherwise idle channels as PDCH
as long as no more TCH's are needed.
Since TS 12.21 implements only SET ATTRIBUTE for some object classes,
ip.access had to extend it to be able to set attributes on arbitrary
objects. We now introduce a function implementing that message.
Supporting GPRS means we have a number of additional OML objects to
deal with. We need to extend our gsm_bts structure to at least
include the nm_state for each of those objects.
Tag-variableLength-Value is an encoding scheme used in the GPRS NS
and BSSGP protocols, where the length value can be 8 or 16 bits,
depending on actual demand.
Partially apply 9ba65525eaa06a1768aaf35bdee98afcf8026e0a to get
rid of a compile problem. The other part of the mentioned commit
is still in the gprs branch.
Signed-off-by: Holger Hans Peter Freyther <zecke@selfish.org>
Add support for 1900 nanoBTS by using unified bts_type
GSM_BTS_TYPE_NANOBTS for 900, 1800 and 1900 versions.
Reduce the nanoBTS enum values to one and derive the
version from the user supplied band. In the future we
might want to do auto band detection.
The configuration file needs to be changed to refer
to nanobts instead of nanobts900/nanobts1800.
Signed-off-by: Mike Haben <michael.haben@btinternet.com>
Signed-off-by: Holger Hans Peter Freyther <zecke@selfish.org>
We are using LAC=0 for remembering that a GSM subscriber is
detached. I recently added code to gsm_bts_by_lac that will
return every BTS in case the lac is 0. Harald highlightes
that we would now search for detached subscribers at every
BTS of our network which is clearly not what we want.
Introduce two defines for the two reserved LAC, add a
pointer to the specification, check that our config files
do not contain these reserved values, use the define
and change gsm_bts_by_lac to use the other define.
For the MSC<->BSC connection we are going to use the same header
as used from BTS<->BSC but we are not having an E1-Link, a gsm network
or a gsm_bts available and can not use this part of the code.
The LAC can be 16bit of size. the generation of the LAI, struct
gsm_subsriber and the BSC<->MSC was already using it as a
16bit (short) value.
Change struct gsm_bts to parse 16bit and change the vty configuration
parsing code to deal with a short too.
Add one method to extract the MI which will allow to load
the gsm_subscriber depending on the MSC/BSC setup and then
use gsm48_handle_paging_resp to finish the paging response
handling.
Transfering the cell_identity from BSC to MSC is required for the
on-waves.com support. Allow to set the cell_identity in the cfg
file and patch the system information tables to set it.
tmsi is four octets long, there is no need to make it a string
and then jump through hoops to convert it to a number. Keep the database
using it as a string to benefit from the NULL handling of the db.
Introduce the reserved tmsi which has all bits set to 1 according
to GSM 03.03 §2.4 and start checking for it and make sure the db
code will never allocate such a tmsi.
This just adds the 04.08 and RSL bits for A5, but not the logic
for performing authentication.
The caller would first set lchan->encr and then call
gsm48_send_rr_ciph_mode(lchan), which encapsulates the 04.08
CIPHERING MODE COMMAND into a RSL ENCRYPTION COMMAND and sends it
to the BTS for execution + forwarding.
Prefix generate_mid_from_tmsi with a gsm48_, create a new method
to binary encode the imsi. Add a unit test for parsing and decoding.
The implementation can parse the data it generated and the
last octet seems to be filled with the end mark.
The existing gsm_04_08.c implementation is mixing BSC and MSC
behavior. Move some simple parsing and generation functions over
to gsm_04_08_utils.c to allow a different MSC to define the policy.
this enables the caller to detect if the paging request was rejected
by the paging layer, especially in case it is already paging this very
subscriber.
In the case of SMS / 04.11, we used to have a memory leak of struct gsm_sms's,
since we would only free them from the paging succeeded/expired callbacks.
SMS related messages are all sent over SAPI=3. But in addition
to that, we also need to send it over the correct link identifier,
i.e. SACCH or main signalling channel
The channel allocator can be set in ascending or descending order.
Ascnending means we first try to allocate channels on TRX0, then TRX1, etc.
Descending means we first try to allocate cahnnels on TRXn, then n-1 down to 0.
SM's need to be transferred over their own RLL connection on SAPI3, rather than
the default SAPI0 connection that we're using for signalling like 04.08
RR/MM/CC.
This is not that much of a problem in the case of SMS SUBMIT from the MS to
the netwrok. In that case, the MS will start its primary RLL connection
with SAPI3, and we can just respond with SAPI3.
However, in the case of SMS DELIVER to a MS, we first page the MS, it then
establishes SAPI0. We then need to explicitly request the establishment of
a SAPI3 RLL connection, before we can send CP-DATA with our RP-DATA and DELIVER
RPDU
Now that we have the bsc_rll.c code, we can actually wait for a paging
response, and from the paging response request the establishment of the SAPI3
connection. We will be called back once that connection is open and can
successively start transmission of the SM.
A caller can call rll_establish(lchan, link_id) and a callback to the GSM RLL
code. He will get called back if the RLL link is established or receives some
error message, or the establishment times out.
We need this for proper SMS implementation, where we need to restablish a SAPI3
RLL link before transmitting the actual CP-DATA messages.
we now have the full path from the MS into the database (SUBMIT), as well as
back from the database to the MS (DELIVER). The database gets correctly
updated once a SMS has been successfully delivered.
What's still missing is the periodic scan over all undelivered messages,
trying to deliver them to the respective MS. So far, you have to manually
trigger this on the telnet interface with 'sms send pending 1'
So far, we immediately disable the RF channel without following a proper
RLL RELEASE procedure. This patch changes this.
If we locally terminate the connection, the channel allocator now triggers a
RLL RELEASE REQuest, which is responsed by the MS with a RLL RELEASE CONFirm,
based on which we send the RF CHANnel RELease to the BTS.
If the MS terminates the connection, we receive a RLL RELEASE INDication,
based on which we trigger RF CHANnel RELease to the BTS.
This helps us to detect the frequency error of BS-11 if it is located
next to the nanoBTS 900.
If 'ipaccess-config -l' is called, it will produce a report like
<0020> ipaccess-config.c:85 TEST REPORT: test_no=0x42 test_res=0
<0020> ipaccess-config.c:108 ==> ARFCN 220, Frequency Error 22
<0020> ipaccess-config.c:108 ==> ARFCN 1, Frequency Error -37
<0020> ipaccess-config.c:108 ==> ARFCN 10, Frequency Error 0
<0020> ipaccess-config.c:108 ==> ARFCN 20, Frequency Error 11
<0020> ipaccess-config.c:108 ==> ARFCN 53, Frequency Error 5
<0020> ipaccess-config.c:108 ==> ARFCN 63, Frequency Error -4
<0020> ipaccess-config.c:108 ==> ARFCN 84, Frequency Error 11
<0020> ipaccess-config.c:108 ==> ARFCN 101, Frequency Error 0
<0020> ipaccess-config.c:108 ==> ARFCN 123, Frequency Error -52
where in this case the ARFCN 123 is the BS-11 with a frequency error
larger than all the other (regular) BTS in the vicinity.
* we only need one piece of code to calculate rsl_ie_chan_mode from
our run-time data structures (gsm_lchan)
* add some more channel modes for TCH/H and data
* use enum's to make the compiler warn us about unhandled enum values
* make sure the caller determines the (signalling,speech,data) mode
Up until now, we only supported direct RTP streams between ip.access BTS.
With this commit, the user can specify '-P' to the command line to enable
a RTP/RTCP proxy inside OpenBSC. The nanoBTS will then send all their voice
data to OpenBSC, which will relay it to the respective destination BTS (which
can be the same BTS).
The default behaviour remains unchanged. Without '-P' on the command line,
RTP/RTCP is exchanged directly.
The rtp_proxy.[ch] code is intended to be used as a transparent
RTP/RTCP proxy, relaying the media streams from one ip.access BTS
to another. In an 'ideal' network, this is obviously not needed,
since the BTS's can send those streams directly between each other.
However, for debugging, 'lawful interception', transcoding or interfacing
a TRAU/E1 based BTS, we actually need to process those RTP streams
ourselves.
Harald Welte
Holger Hans Peter Freyther
Sylvain Munaut