diff options
Diffstat (limited to 'doc')
-rw-r--r-- | doc/call-routing.txt | 25 | ||||
-rw-r--r-- | doc/e1-data-model.txt | 172 | ||||
-rw-r--r-- | doc/examples/osmo-bsc_nat/bscs.cfg | 13 | ||||
-rw-r--r-- | doc/examples/osmo-sgsn/osmo-sgsn-accept-all.cfg | 27 | ||||
-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/osmo-nitb-data_structures.dot | 33 | ||||
-rw-r--r-- | doc/paging.txt | 48 |
9 files changed, 0 insertions, 555 deletions
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/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_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-sgsn/osmo-sgsn-accept-all.cfg b/doc/examples/osmo-sgsn/osmo-sgsn-accept-all.cfg deleted file mode 100644 index 5e6434263..000000000 --- a/doc/examples/osmo-sgsn/osmo-sgsn-accept-all.cfg +++ /dev/null @@ -1,27 +0,0 @@ -! -! Osmocom SGSN configuration -! -! -line vty - no login -! -sgsn - gtp local-ip 127.0.0.1 - ggsn 0 remote-ip 127.0.0.2 - ggsn 0 gtp-version 1 - auth-policy accept-all -! -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 127.0.0.1 - encapsulation udp local-port 23000 - encapsulation framerelay-gre enabled 0 -! -bssgp -! 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/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. |