diff options
author | Neels Hofmeyr <neels@hofmeyr.de> | 2017-09-04 03:35:30 +0200 |
---|---|---|
committer | Neels Hofmeyr <neels@hofmeyr.de> | 2017-09-06 16:47:47 +0200 |
commit | 1e52928ad9e87f2db0a9abe0ba37d2c9c2629463 (patch) | |
tree | 21581a95387fb508d5ac12bfb62fb572be4aaffc /doc | |
parent | 075cac02b0e346e1fdb1176f7434a900999ec6f5 (diff) |
drop files unrelated to osmo-sgsn
These either remain from openbsc.git or slipped in while applying recent
patches from openbsc.git and do not belong in osmo-sgsn.
Change-Id: Ie9dc7514c3850010d0e9b3ab716b4f4e8d83594f
Diffstat (limited to 'doc')
-rw-r--r-- | doc/BS11-OML.txt | 31 | ||||
-rw-r--r-- | doc/call-routing.txt | 25 | ||||
-rw-r--r-- | doc/channel_release.txt | 95 | ||||
-rw-r--r-- | doc/e1-data-model.txt | 172 | ||||
-rw-r--r-- | doc/examples/osmo-bsc/osmo-bsc.cfg | 101 | ||||
-rw-r--r-- | doc/examples/osmo-bsc_mgcp/mgcp.cfg | 19 | ||||
-rw-r--r-- | doc/examples/osmo-bsc_nat/black-list.cfg | 1 | ||||
-rw-r--r-- | doc/examples/osmo-bsc_nat/bscs.cfg | 13 | ||||
-rw-r--r-- | doc/examples/osmo-bsc_nat/osmo-bsc_nat.cfg | 66 | ||||
-rw-r--r-- | doc/examples/osmo-msc/osmo-msc.cfg | 19 | ||||
-rw-r--r-- | doc/gsm-hopping.txt | 54 | ||||
-rw-r--r-- | doc/handover.txt | 89 | ||||
-rw-r--r-- | doc/ipa-sccp.txt | 94 | ||||
-rw-r--r-- | doc/oml-interface.txt | 22 | ||||
-rw-r--r-- | doc/osmo-nitb-data_structures.dot | 33 | ||||
-rw-r--r-- | doc/paging.txt | 48 |
16 files changed, 0 insertions, 882 deletions
diff --git a/doc/BS11-OML.txt b/doc/BS11-OML.txt deleted file mode 100644 index e5c3299c9..000000000 --- a/doc/BS11-OML.txt +++ /dev/null @@ -1,31 +0,0 @@ -The Siemens BS-11 supports the following additional GSM 12.21 OML operations: - - -CREATE OBJECT - -abis_om_fom_hdr.obj_class can be -A3: -A5: ALCO, BBSIG, CCLK, GPSU, LI, PA -A8: EnvaBTSE -A9: BPORT - -the abis_om_obj_inst.trx_nr field indicates the index of object, whereas the -abis_om_fom_hdr.bts_nr indicates the type of the object. - -enum abis_bs11_objtype { - BS11_OBJ_ALCO = 0x01, - BS11_OBJ_BBSIG = 0x02, /* obj_class: 0,1 */ - BS11_OBJ_TRX1 = 0x03, /* only DEACTIVATE TRX1 */ - BS11_OBJ_CCLK = 0x04, - BS11_OBJ_GPSU = 0x06, - BS11_OBJ_LI = 0x07, - BS11_OBJ_PA = 0x09, /* obj_class: 0, 1*/ -}; - -In case of CREATE ENVABTSE, the abis_om_obj_inst.trx_nr indicates the EnvaBTSEx -number. - -In case of A9 (CREAETE BPORT), the abis_om_obj_inst.bts_nr indicates which BPORT -shall be used. - - diff --git a/doc/call-routing.txt b/doc/call-routing.txt deleted file mode 100644 index 3402f9e33..000000000 --- a/doc/call-routing.txt +++ /dev/null @@ -1,25 +0,0 @@ -Call routing in OpenBSC - -Flow of events: - - # MO call initiated by MS, CHANNEL RQD, IMMEDIATE ASSIGN - # MS sends CC SETUP message, we assume already on TCH/H FACCH - # OpenBSC does a subscriber lookup based on the target extension - * If a subscriber is found: - # send CALL PROCEEDING message to MO - # page the MT subscriber and ask itI to ask for TCH/H - # once paging completes, we have the TCH/H for the MT end - # send SETUP to MT - # receive CALL CONFIRMED from MT - # set-up the TRAU mux mapping between the E1 subslots for both TCH/H - # receive ALERTING from MT, route ALERTING to MO - # receive CONNECT from MT, confirm to MT with CONNECT_ACK - # send a CONNECT message to MO, receive CONNECT_ACK from MO - * If subscriber is not found: - # send RELEASE COMPLETE with apropriate cause to MO (1: unalloacated 3: no route) - - - -Thoughts about RR/MM: - -* we allocate RR/MM entities on demand, when we need them diff --git a/doc/channel_release.txt b/doc/channel_release.txt deleted file mode 100644 index c9cdfebca..000000000 --- a/doc/channel_release.txt +++ /dev/null @@ -1,95 +0,0 @@ - -GSM 04.08 7.1.7 / 9.1.7 RR CHANNEL RELESE - -RSL 08.58 3.4 / ? RLL Link Release Request - -RSL 08.58 4.6 / 8.4.5 DEACTivate SACCH - * Deactivate SACCH according to Channel Release Proc 04.08 - * to be sent after RR CHANNEL RELEASE is sent to MS - -RSL 08.58 4.7 / 8.4.14 RF CHANnel RELease - * tells the BTS to release a radio channel - * "when an activated radio channel is no longer needed" - * BTS responds with RF CHANnel RELease ACKnowledge - - -GSM 04.08 3.4.13: RR connection release procedure - -* network sends RR CHANNEL RELEASE to MS on the DCCH - * start T3109 - * deactivate SACCH -* MS disconnects main signalling link (by sending DISC) - * all other data links are disconnected by local end link release -* network receives DISC (BTS sends RLL REL IND to BSC) - * stop T3109 - * start T3111 -* when T3111 times out, the network can reuse the channls -* if T3109 times out, the network deactivates the channels - and can reuse them - * this probably means simply RF CHANnel RELease - - -== Implementation in OpenBSC == - -There are two possible reasons a gsm_subscriber_connection -will be released. One is a network failure, the other is -the completion of an operation/transaction. - -=== Failure === -The BSC API will call the gsm_04_08.c:gsm0408_clear_request callback -and the MSC part will release all transactions, operations and such -and the channels will be released as error case. - -=== Success === -Every time an 'operation' or 'transaction' is finished msc_release_connection -will be called and it will determine if the gsm_subscriber_connection can -be released. - -In case it can be released bsc_api.c:gsm0808_clear will be called -which will release all lchan's associated with the connection. For the -primary channel a SACH Deactivate will be send with the release -reason NORMAL RELEASE. - - -bsc_api.c:gsm0808_clear - * Release a channel used for handover - * Release the primary lchan with normal release, SACH deactivate - -chan_alloc.c:lchan_release(chan, sacch_deactivate, reason) - * Start the release procedure. It is working in steps with callbacks - coming from the abis_rsl.c code. - * Release all SAPI's > 0 as local end (The BTS should send a - REL_CONF a message) - * Send SACH Deactivate on SAPI=0 if required. - * Start T3109 (stop it when the main signalling link is disconnected) - or when the channel released. On timeout start the error handling. - * abis_rsl.c schedules the RSL_MT_RF_CHAN_REL once all SAPI's are - released and after T3111 has timed out or there is an error. - -RX of RELease INDication: - * Calls internal rsl_handle_release which might release the RF. - -RX of RELease CONFirmation: - * Calls internal rsl_handle_release which might release the RF. - -* RX of RF_CHAN_REL_ACK - * call lchan_free() - - -=== Integration with SMS === - -* RX of CP_ERROR or unimplemented MT - * trigger trans_free() which will msc_release_connection() - -* CP TC1* expired while waiting for CP-ACK - * trigger trans_free() which will msc_release_connection() - -* RX of RP_ERROR - * trigger trans_free() which will msc_release_connection() - -* TX of CP-ACK in MT DELIVER - * trigger trans_free() which will msc_release_connection() - -* RX of CP-ACK in MO SUBMIT - * trigger trans_free() which will msc_release_connection() - diff --git a/doc/e1-data-model.txt b/doc/e1-data-model.txt deleted file mode 100644 index 509004fe9..000000000 --- a/doc/e1-data-model.txt +++ /dev/null @@ -1,172 +0,0 @@ -E1 related data model - -This data model describes the physical relationship of the individual -parts in the network, it is not the logical/protocol side of the GSM -network. - -A BTS is connected to the BSC by some physical link. It could be an actual -E1 link, but it could also be abis-over-IP with a mixture of TCP and RTP/UDP. - -To further complicate the fact, multiple BTS can share one such pysical -link. On a single E1 line, we can easily accomodate up to three BTS with -two TRX each. - -Thus, it is best for OpenBSC to have some kind of abstraction layer. The BSC's -view of a BTS connected to it. We call this 'bts_link'. A bts_link can be -* all the TCP and UDP streams of a Abis-over-IP BTS -* a set of E1 timeslots for OML, RSL and TRAU connections on a E1 link -* a serial line exclusively used for OML messages (T-Link) - -A bts_link can be registered with the OpenBSC core at runtime. - -struct trx_link { - struct gsm_bts_trx *trx; -}; - -struct bts_link { - struct gsm_bts *bts; - struct trx_link trx_links[NUM_TRX]; -}; - -Interface from stack to input core: -====================================================================== -int abis_rsl_sendmsg(struct msgb *msg); - send a message through a RSL link to the TRX specified by the caller in - msg->trx. - -int abis_rsl_rcvmsg(struct msgb *msg); - receive a message from a RSL link from the TRX specified by the - caller in msg->trx. - -int abis_nm_sendmsg(struct msgb *msg); - send a message through a OML link to the BTS specified by the caller in - msg->trx->bts. The caller can just use bts->c0 to get the first TRX - in a BTS. (OML messages are not really sent to a TRX but to the BTS) - -int abis_nm_rcvmsg(struct msgb *msg); - receive a message from a OML link from the BTS specified by the caller - in msg->trx->bts. The caller can just use bts->c0 to get the first - TRX in a BTS. - -int abis_link_event(int event, void *data); - signal some event (such as layer 1 connect/disconnect) from the - input core to the stack. - -int subch_demux_in(mx, const uint8_t *data, int len); - receive 'len' bytes from a given E1 timeslot (TRAU frames) - -int subchan_mux_out(mx, uint8_t *data, int len); - obtain 'len' bytes of output data to be sent on E1 timeslot - -Intrface by Input Core for Input Plugins -====================================================================== - -int btslink_register_plugin(); - - -Configuration for the E1 input module -====================================================================== - -BTS - BTS number - number of TRX - OML link - E1 line number - timeslot number - [subslot number] - SAPI - TEI - for each TRX - RSL link - E1 line number - timeslot number - [subslot number] - SAPI - TEI - for each TS - E1 line number - timeslot number - subslot number - - -E1 input module data model -====================================================================== - - -enum e1inp_sign_type { - E1INP_SIGN_NONE, - E1INP_SIGN_OML, - E1INP_SIGN_RSL, -}; - -struct e1inp_sign_link { - /* list of signalling links */ - struct llist_head list; - - enum e1inp_sign_type type; - - /* trx for msg->trx of received msgs */ - struct gsm_bts_trx *trx; - - /* msgb queue of to-be-transmitted msgs */ - struct llist_head tx_list; - - /* SAPI and TEI on the E1 TS */ - uint8_t sapi; - uint8_t tei; -} - -enum e1inp_ts_type { - E1INP_TS_TYPE_NONE, - E1INP_TS_TYPE_SIGN, - E1INP_TS_TYPE_TRAU, -}; - -/* A timeslot in the E1 interface */ -struct e1inp_ts { - enum e1inp_ts_type type; - struct e1inp_line *line; - union { - struct { - struct llist_head sign_links; - } sign; - struct { - /* subchannel demuxer for frames from E1 */ - struct subch_demux demux; - /* subchannel muxer for frames to E1 */ - struct subch_mux mux; - } trau; - }; - union { - struct { - /* mISDN driver has one fd for each ts */ - struct osmo_fd; - } misdn; - } driver; -}; - -struct e1inp_line { - unsigned int num; - char *name; - - struct e1inp_ts ts[NR_E1_TS]; - - char *e1inp_driver; - void *driver_data; -}; - -/* Call from the Stack: configuration of this TS has changed */ -int e1inp_update_ts(struct e1inp_ts *ts); - -/* Receive a packet from the E1 driver */ -int e1inp_rx_ts(struct e1inp_ts *ts, struct msgb *msg, - uint8_t tei, uint8_t sapi); - -/* Send a packet, callback function in the driver */ -int e1driver_tx_ts(struct e1inp_ts *ts, struct msgb *msg) - - -struct e1inp_driver { - const char *name; - int (*want_write)(struct e1inp_ts *ts); -}; diff --git a/doc/examples/osmo-bsc/osmo-bsc.cfg b/doc/examples/osmo-bsc/osmo-bsc.cfg deleted file mode 100644 index 7c10e9dea..000000000 --- a/doc/examples/osmo-bsc/osmo-bsc.cfg +++ /dev/null @@ -1,101 +0,0 @@ -! -! OsmoBSC (0.9.14+gitr1+3d331c0062bb0c9694dbd4d1eab7adc58138c3ae) 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 OsmoBSC - long name OsmoBSC - auth policy closed - location updating reject cause 13 - encryption a5 0 - neci 1 - paging any use tch 0 - 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 - 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 - dtx uplink force - dtx downlink - ip.access unit_id 0 0 - oml ip.access stream_id 255 line 0 - neighbor-list mode manual-si5 - neighbor-list add arfcn 100 - neighbor-list add arfcn 200 - si5 neighbor-list add arfcn 10 - si5 neighbor-list add arfcn 20 - gprs mode none - trx 0 - rf_locked 0 - arfcn 871 - nominal power 23 - max_power_red 20 - rsl e1 tei 0 - timeslot 0 - phys_chan_config CCCH+SDCCH4 - hopping enabled 0 - timeslot 1 - phys_chan_config TCH/F - hopping enabled 0 - timeslot 2 - phys_chan_config TCH/F - hopping enabled 0 - timeslot 3 - phys_chan_config TCH/F - hopping enabled 0 - timeslot 4 - phys_chan_config TCH/F - hopping enabled 0 - timeslot 5 - phys_chan_config TCH/F - hopping enabled 0 - timeslot 6 - phys_chan_config TCH/F - hopping enabled 0 - timeslot 7 - phys_chan_config TCH/F - hopping enabled 0 -cs7 instance 1 - point-code 3.0.0 - sccp-address bsc_local - point-code 3.0.0 - sccp-address msc_remote - point-code 1.0.0 -msc - bsc-addr bsc_local - msc-addr msc_remote - ip.access rtp-base 4000 - timeout-ping 20 - timeout-pong 5 - dest 192.168.100.11 6666 0 - access-list-name msc-list - no access-list-name -bsc - no access-list-name - access-list-name bsc-list diff --git a/doc/examples/osmo-bsc_mgcp/mgcp.cfg b/doc/examples/osmo-bsc_mgcp/mgcp.cfg deleted file mode 100644 index 3c43f1feb..000000000 --- a/doc/examples/osmo-bsc_mgcp/mgcp.cfg +++ /dev/null @@ -1,19 +0,0 @@ -! -! MGCP configuration hand edited -! ! -password foo -! -line vty - no login -! -mgcp - !local ip 10.23.24.2 - !bts ip 10.24.24.1 - !bind ip 10.23.24.1 - bind port 2427 - rtp base 4000 - rtp force-ptime 20 - sdp audio payload number 98 - sdp audio payload name AMR/8000 - number endpoints 31 - no rtcp-omit diff --git a/doc/examples/osmo-bsc_nat/black-list.cfg b/doc/examples/osmo-bsc_nat/black-list.cfg deleted file mode 100644 index d36179d37..000000000 --- a/doc/examples/osmo-bsc_nat/black-list.cfg +++ /dev/null @@ -1 +0,0 @@ -678012512671923:6:6: diff --git a/doc/examples/osmo-bsc_nat/bscs.cfg b/doc/examples/osmo-bsc_nat/bscs.cfg deleted file mode 100644 index 176debe42..000000000 --- a/doc/examples/osmo-bsc_nat/bscs.cfg +++ /dev/null @@ -1,13 +0,0 @@ -nat - bsc 0 - token lol - location_area_code 1234 - description bsc - max-endpoints 32 - paging forbidden 0 - bsc 1 - token wat - location_area_code 5678 - description bsc - max-endpoints 32 - paging forbidden 0 diff --git a/doc/examples/osmo-bsc_nat/osmo-bsc_nat.cfg b/doc/examples/osmo-bsc_nat/osmo-bsc_nat.cfg deleted file mode 100644 index e835e068a..000000000 --- a/doc/examples/osmo-bsc_nat/osmo-bsc_nat.cfg +++ /dev/null @@ -1,66 +0,0 @@ -! -! OsmoBSCNAT (0.12.0.266-2daa9) configuration saved from vty -!! -! -log stderr - logging filter all 1 - logging color 1 - logging timestamp 0 - logging level all debug - logging level rll notice - logging level cc notice - logging level mm notice - logging level rr notice - logging level rsl notice - logging level nm info - logging level mncc notice - logging level pag notice - logging level meas notice - logging level sccp notice - logging level msc notice - logging level mgcp notice - logging level ho notice - logging level db notice - logging level ref notice - logging level gprs debug - logging level ns info - logging level bssgp debug - logging level llc debug - logging level sndcp debug - logging level nat notice - logging level ctrl notice - logging level smpp debug - logging level lglobal notice - logging level llapd notice - logging level linp notice - logging level lmux notice - logging level lmi notice - logging level lmib notice - logging level lsms notice -! -line vty - no login -! -mgcp - bind ip 0.0.0.0 - bind port 2427 - rtp bts-base 4000 - rtp net-base 16000 - rtp ip-dscp 0 - no rtcp-omit - sdp audio-payload number 126 - sdp audio-payload name AMR/8000 - loop 0 - number endpoints 1 - call-agent ip 127.0.0.1 - rtp transcoder-base 0 - transcoder-remote-base 4000 -nat - msc ip 127.0.0.1 - msc port 5000 - timeout auth 2 - timeout ping 20 - timeout pong 5 - ip-dscp 0 - bscs-config-file bscs.cfg - access-list bla imsi-allow ^11$ diff --git a/doc/examples/osmo-msc/osmo-msc.cfg b/doc/examples/osmo-msc/osmo-msc.cfg deleted file mode 100644 index 1b1d19258..000000000 --- a/doc/examples/osmo-msc/osmo-msc.cfg +++ /dev/null @@ -1,19 +0,0 @@ -! -! OsmoMSC configuration saved from vty -! -line vty - no login -! -network - network country code 1 - mobile network code 1 - short name OsmoMSC - long name OsmoMSC - auth policy closed - location updating reject cause 13 - encryption a5 0 - rrlp mode none - mm info 1 -msc - mgcpgw remote-ip 10.23.24.1 - assign-tmsi diff --git a/doc/gsm-hopping.txt b/doc/gsm-hopping.txt deleted file mode 100644 index c964963c0..000000000 --- a/doc/gsm-hopping.txt +++ /dev/null @@ -1,54 +0,0 @@ -according to GSM 05.02: - -general parameters from CCCH: -* CA cell allocation of ARFCN's (System Information / BCCH) -* FN: TDMA frame number (t1,t2,t3') in SCH - -specific parameters from channel assignment: -* MA: mobile allocation, defines set of ARFCN's, up to 64 -* MAIO: index -* HSN: hopping sequence generator number (0..64) - - -hopping sequence generation (6.2.3): - -uint8_t rntable[114] = { - 48, 98, 63, 1, 36, 95, 78, 102, 94, 73, - 0, 64, 25, 81, 76, 59, 124, 23, 104, 100, - 101, 47, 118, 85, 18, 56, 96, 86, 54, 2, - 80, 34, 127, 13, 6, 89, 57, 103, 12, 74, - 55, 111, 75, 38, 109, 71, 112, 29, 11, 88, - 87, 19, 3, 68, 110, 26, 33, 31, 8, 45, - 82, 58, 40, 107, 32, 5, 106, 92, 62, 67, - 77, 108, 122, 37, 60, 66, 121, 42, 51, 126, - 117, 114, 4, 90, 43, 52, 53, 113, 120, 72, - 16, 49, 7, 79, 119, 61, 22, 84, 9, 97, - 125, 99, 17, 123 -}; - -/* mai=0 represents lowest ARFCN in the MA */ - - -uint8_t hopping_mai(uint8_t hsn, uint32_t fn, uint8_t maio, - uint8_t t1, uint8_t t2, uint8_t t3_) -{ - uint8_t mai; - - if (hsn == 0) /* cyclic hopping */ - mai = (fn + maio) % n; - else { - uint32_t m, m_, t_, s; - - m = t2 + rntable[(hsn xor (t1 % 64)) + t3]; - m_ = m % (2^NBIN); - t_ = t3 % (2^NBIN); - if (m_ < n then) - s = m_; - else - s = (m_ + t_) % n; - mai = (s + maio) % n; - } - - return mai; -} - diff --git a/doc/handover.txt b/doc/handover.txt deleted file mode 100644 index ac19e8725..000000000 --- a/doc/handover.txt +++ /dev/null @@ -1,89 +0,0 @@ -Ideas about a handover algorithm -====================================================================== - -This is mostly based on the results presented in Chapter 8 of "Performance -Enhancements in a Frequency Hopping GSM Network" by Thomas Toftegaard Nielsen -and Joeroen Wigard. - - -=== Reasons for performing handover === - -Section 2.1.1: Handover used in their CAPACITY simulation: - -1) Interference Handover - -Average RXLEV is satisfactory high, but average RXQUAL too low indicates -interference to the channel. Handover should be made. - -2) Bad Quality - -Averaged RXQUAL is lower than a threshold - -3) Low Level / Signal Strength - -Average RXLEV is lower than a threshold - -4) Distance Handover - -MS is too far away from a cell (measured by TA) - -5) Power budget / Better Cell - -RX Level of neighbor cell is at least "HO Margin dB" dB better than the -current serving cell. - -=== Ideal parameters for HO algorithm === - -Chapter 8, Section 2.2, Table 24: - -Window RXLEV averaging: 10 SACCH frames (no weighting) -Window RXQUAL averaging: 1 SACCH frame (no averaging) -Level Threashold: 1 of the last 1 AV-RXLEV values < -110dBm -Quality Threshold: 3 of the last 4 AV-RXQUAL values >= 5 -Interference Threshold: 1 of the last AV-RXLEV > -85 dBm & - 3 of the last 4 AV-RXQUAL values >= 5 -Power Budget: Level of neighbor cell > 3 dB better -Power Budget Interval: Every 6 SACCH frames (6 seconds ?!?) -Distance Handover: Disabled -Evaluation rule 1: RXLEV of the candidate cell a tleast -104 dBm -Evaluation rule 2: Level of candidate cell > 3dB better own cell -Timer Successful HO: 5 SACCH frames -Timer Unsuccessful HO: 1 SACCH frame - -In a non-frequency hopping case, RXQUAL threshold can be decreased to -RXLEV >= 4 - -When frequency hopping is enabled, the following additional parameters -should be introduced: - -* No intra-cell handover -* Use a HO Margin of 2dB - -=== Handover Channel Reservation === - -In loaded network, each cell should reserve some channels for handovers, -rather than using all of them for new call establishment. This reduces the -need to drop calls due to failing handovers, at the expense of failing new call -attempts. - -=== Dynamic HO Margin === - -The handover margin (hysteresis) should depend on the RXQUAL. Optimal results -were achieved with the following settings: -* RXQUAL <= 4: 9 dB -* RXQUAL == 5: 6 dB -* RXQUAL >= 6: 1 dB - - - -== Actual Handover on a protocol level == - -After the BSC has decided a handover shall be done, it has to - -# allocate a channel at the new BTS -# allocate a handover reference -# activate the channel on the BTS side using RSL CHANNEL ACTIVATION, - indicating the HO reference -# BTS responds with CHAN ACT ACK, including GSM frame number -# BSC sends 04.08 HO CMD to MS using old BTS - diff --git a/doc/ipa-sccp.txt b/doc/ipa-sccp.txt deleted file mode 100644 index 5d6719e98..000000000 --- a/doc/ipa-sccp.txt +++ /dev/null @@ -1,94 +0,0 @@ - -IPA SCCP message flow in the BSC - -February, 2013 Holger Hans Peter Freyther - -CONTENTS - -1. SCCP inside the IPA header -2. Supported SCCP message types -3. Receiving SCCP messages -4. Sending SCCP messages - - -1. SCCP inside the IPA header - -Many Soft-MSCs implement something that is called SCCP/lite. This means -that SCCP messages are transported inside a small multiplexing protocol -over TCP/IP. This is an alternative to a full SIGTRAN implementation. - -The multiplexing protocol is the same as used with the sysmoBTS and the -ip.access nanoBTS. It is a three byte header with two bytes for the length -in network byte order and one byte for the type. The type to be used for -SCCP is 0xFD. - - struct ipa_header { - uint16_t length_in_network_order; - uint8_t type; - } __attribute__((packed)); - - - -2. Supported SCCP message types - -To implement GSM 08.08 only a subset of SCCP messages need to be implemented. -For transporting paging and reset messages SCCP UDT messages are used. For -the connections with a Mobile Station (MS) a SCCP connection is opened. This -means that the SCCP CR, SCCP CC, SCCP CREF, SCCP RLC, SCCP RLSD, SCCP DT1 -and SCCP IT messages are supported. - - -3. Receiving SCCP UDT messages - -This is an illustration of the flow of messages. The IPA multiplexing protocol -is used for various protocols. This means there is a central place where the -multiplexing stream terminates. The stream is terminated in the osmo_bsc_msc.c -file and the ipaccess_a_fd_cb method. For SCCP messages the SCCP dispatching -sccp_system_incoming method is called. This function is implemented in the -libosmo-sccp library. - -To receive UDT messages osmo_bsc_sccp.c:osmo_bsc_sccp_init is using the -sccp_set_read function to register a callback for UDT messages. The callback -is msc_sccp_read and it is calling bsc_handle_udt that is implemented in the -osmo_bsc_bssap.c. This function will handle the GSM 08.08 BSSAP messages. -Currently only the reset acknowledge and the paging messages are handled. - -The BSC currently does not accept incoming SCCP messages and is only opening -SCCP connections to the MSC. When opening a connection the callbacks for state -changes (connection confirmed, released, release complete) are set and a routine -for handling incoming data. This registration is done in the osmo_bsc_sccp.c -file and the bsc_create_new_connection method. The name of the callback is -msc_outgoing_sccp_data and this will call bsc_handle_dt1 that is implemented -in the osmo_bsc_bssap.c file. This will forward the messages to the right -Mobile Station (MS). - - -4. Sending SCCP messages - -There are three parts to sending that will be explained below. The first part -is to send an entire SCCP frame (which includes the GSM 08.08 data) to the -MSC. This is done by first registering the low level sending. sccp_system_init -is called with the function that is responsible for sending a message. The -msc_sccp_write_ipa will call the msc_queue_write function with the data and -the right MSC connection. Below the msc_queue_write the IPA header will be -prepended to the msg and then send to the MSC. - -The BSC supports multiple different A-link connections, the decision to pick -the right MSC is done in this method. It is either done via the SCCP connection -or the ctx pointer. - -When the BSC is starting a BSS RESET message will be sent to the MSC. The reset -is created in osmo_bsc_msc.c:initialize_if_needed and sccp_write is called with -the GSM 08.08 data and the connection to use. The libosmo-sccp library will -embed it into a SCCP UDT message and call the msc_sccp_write_ipa method. - -When a new SCCP connection is to be created the bsc_create_new_connection -in the osmo_bsc_sccp.c file. The sccp_connection_socket method will create -the context for a SCCP connection. The state and data callback will be used -to be notified about data and changes. Once the connection is configured the -bsc_open_connection will be called that will ask the libosmo-sccp library to -create a SCCP CR message using the sccp_connection_connect method. For active -connections the sccp_connection_write method will be called. - - - diff --git a/doc/oml-interface.txt b/doc/oml-interface.txt deleted file mode 100644 index 02bead77a..000000000 --- a/doc/oml-interface.txt +++ /dev/null @@ -1,22 +0,0 @@ -oml interface design notes - -problems: - -* there is no way how to tag a command sent to the BTS, with the response - having the same tag to identify the originator of the command -* therefore, we can have e.g. both the BSC and the OML interface send a - SET ATTRIBUTE message, where the responses would end up at the wrong - query. -* The BTS has 10s to ACK/NACK a command. We do not run any timers. - -the only possible solutions i can imagine: -* have some kind of exclusive locking, where the OML interface gets blocked - from the BSC and is exclusively assigned to the OML console until all commands - of the OML console have terminated. This can either be done explicitly - dynamically or on demand - -* use the OML interface synchronously, i.e. always wait for the response from - the BTS before - -* unilateral / unsolicited messages need to be broadcasted to both the BSC and - the OML console diff --git a/doc/osmo-nitb-data_structures.dot b/doc/osmo-nitb-data_structures.dot deleted file mode 100644 index 81955e8b9..000000000 --- a/doc/osmo-nitb-data_structures.dot +++ /dev/null @@ -1,33 +0,0 @@ -digraph G { - net [label="gsm_network"] - bts [label="gsm_bts"] - trx [label="gsm_bts_trx"] - ts [label="gsm_bts_trx_ts"] - lchan [label="gsm_lchan"] - sub [label="gsm_subscriber"] - subcon [label="gsm_subscriber_conn"] - sccpcon [label="osmo_bsc_sccp_con"] - subgrp [label="gsm_subscriber_group"] - - net -> bts - bts -> trx - trx -> ts - ts -> lchan - - lchan -> ts - ts -> trx - trx -> bts - bts -> net - - lchan -> subcon - - subcon -> sub - subcon -> sccpcon - subcon -> lchan - subcon -> lchan [label="ho_lchan"] - subcon -> bts - subcon -> lchan [label="secondary_lchan"] - - sub -> subgrp - subgrp -> net -} diff --git a/doc/paging.txt b/doc/paging.txt deleted file mode 100644 index c597c22b4..000000000 --- a/doc/paging.txt +++ /dev/null @@ -1,48 +0,0 @@ - -GSM Paging implementation in OpenBSC - -== Code structure == - -The code is implemented in the libbsc/paging.c file. The external -interface is documented/specified in the include/openbsc/paging.h -header file. The code is used by the NITB and BSC application. - - -== Implementation == - -Paging can be initiated in two ways. The standard way is to page by -LAC. Each BTS has its own list/queue of outstanding paging operation. -When a subscriber is paged one "struct paging_request" per BTS will -be allocated and added to the tail of the list. The BTS is supposed -to be configured to not repeat the paging. - -A paging_request will remain in the queue until a paging response or at -the expiry of the T3113. Every 500 milliseconds a RSL paging command is -send to the BTS. The 500 milliseconds is a throttling to not crash the -ip.access nanoBTS. Once one paging_request has been handled it will be -put at the end of the queue/list and the available slots for the BTS -will be decreased. - -The available slots will be updated based on the paging load information -element of the CCCH Load indication. If no paging slots are considered -to be available and no load indication is sent a timer is started. The -current timeout is 500 milliseconds and at the expiry of the timer the -available slots will be set to 20. - -OpenBSC has the " paging free <-1-1024>" configuration option. In case -there are less free channels than required no paging request will be -sent to the BTS. Instead it will be attempted to send the paging request -at the next timeout (500 milliseconds). - -== Limitation == - -The paging throughput could be higher but this has lead to crashes on the -ip.access nanoBTS in the past. - -== Configuration == - -=== ip.access nanoBTS === - -The current CCCH Load indication threshold is 10% and the period is 1 second. -The code can be found inside the src/libbsc/bts_ipaccess_nanobts.c inside the -nanobts_attr_bts array. |