Cellular Network Infrastructure » cni-legacy » OpenBSC

• http://www.3gpp.org/DynaReport/43903.htm
  • study on how to implenent AoIP, before spec was written
  • explains the overall problem area and possible solutions
  • direct link: http://www.etsi.org/deliver/etsi_tr/143900_143999/143903/13.00.00_60/tr_143903v130000p.pdf
• http://www.3gpp.org/DynaReport/WiCr--50589.htm
  • lists of change items related to AoIP
  • most important change item for us:
    • http://www.3gpp.org/ftp/tsg_geran/TSG_GERAN/GERAN_39_Florence/docs/GP-081397.zip
    • http://www.3gpp.org/ftp/tsg_geran/TSG_GERAN/GERAN_39_Florence/docs/GP-081400.zip
    • http://www.3gpp.org/ftp/tsg_geran/TSG_GERAN/GERAN_40_Miami/Docs/GP-081874.zip
    • http://www.3gpp.org/ftp/tsg_geran/TSG_GERAN/GERAN_40_Miami/Docs/GP-081542.zip
    • http://www.3gpp.org/ftp/tsg_geran/TSG_GERAN/GERAN_40_Miami/Docs/GP-081556.zip
    • http://www.3gpp.org/ftp/tsg_geran/TSG_GERAN/GERAN_40_Miami/Docs/GP-081465.zip
    • http://www.3gpp.org/ftp/tsg_geran/TSG_GERAN/GERAN_40_Miami/Docs/GP-081928.zip
    • http://www.3gpp.org/ftp/tsg_geran/TSG_GERAN/GERAN_40_Miami/Docs/GP-081679.zip
    • http://www.3gpp.org/ftp/tsg_geran/TSG_GERAN/GERAN_40_Miami/Docs/GP-081879.zip
    • http://www.3gpp.org/ftp/tsg_geran/TSG_GERAN/GERAN_40_Miami/Docs/GP-081715.zip
    • http://www.3gpp.org/ftp/tsg_geran/TSG_GERAN/GERAN_40_Miami/Docs/GP-081876.zip
    • http://www.3gpp.org/ftp/tsg_geran/TSG_GERAN/GERAN_40_Miami/Docs/GP-081936.zip
    • http://www.3gpp.org/ftp/tsg_geran/TSG_GERAN/GERAN_41_Malta/docs/GP-090269.zip
    • http://www.3gpp.org/ftp/tsg_geran/TSG_GERAN/GERAN_41_Malta/docs/GP-090133.zip
    • http://www.3gpp.org/ftp/tsg_geran/TSG_GERAN/GERAN_41_Malta/docs/GP-090140.zip
    • http://www.3gpp.org/ftp/tsg_geran/TSG_GERAN/GERAN_42_Shenzhen/Docs/GP-090816.zip
    • http://www.3gpp.org/ftp/tsg_geran/TSG_GERAN/GERAN_41_Malta/docs/GP-090134.zip
    • http://www.3gpp.org/ftp/tsg_geran/TSG_GERAN/GERAN_41_Malta/docs/GP-090283.zip
• http://www.3gpp.org/DynaReport/WiCr--50591.htm

I have reviewed the change requests and created an overview to point out where messages had changed. See the attached file. Each line marked with a # indicates that there is a change that directly affects the message type (by adding/changing codings or adding elements).

I have now reviewed the source code. When I get things correct, the following messages types have to be updated:

+ASSIGNMENT REQUEST        (BSS_MAP_MSG_ASSIGMENT_RQST, rx only, osmo_bsc_bssap.c)
+ASSIGNMENT COMPLETE        (BSS_MAP_MSG_ASSIGMENT_COMPLETE, gsm0808_create_assignment_completed())        test exists
+ASSIGNMENT FAILURE        (BSS_MAP_MSG_ASSIGMENT_FAILURE, gsm0808_create_assignment_failure())        test exists
 CLEAR COMMAND
 CLEAR COMPLETE
 CLEAR REQUEST
 RESET
 RESET ACK
 PAGING
 CLASSMARK UPDATE
 CIPHER MODE COMMAND
 CIPHER MODE COMPLETE
 CIPHER MODE REJECT
+COMPLETE LAYER 3 INFORMATION    (BSS_MAP_MSG_COMPLETE_LAYER_3, gsm0808_create_layer3())                test exists
 SAPI "N" REJECT

(+ means, message needs to be patched)

We have now an encoder / decoder plus tests for "AoIP Transport Layer Address" and an encoder for "Speech Codec Element". (see also libosmocore.git pmaier/aoip)

When I get the osmo-bsc / libosmocore code and the spec right. Then we only need the following additional fields for the BSC case:
AoIP Transport Layer Address (MGW)
Codec List (MSC Preferred)
Call Identifier

Judging by the messages osmo-bsc can unsterstand, we would need generator functions for the following messages:
BSS_MAP_MSG_PAGING
BSS_MAP_MSG_CIPHER_MODE_CMD
BSS_MAP_MSG_ASSIGMENT_RQST

(I have attached some of my notes with some more details about what is missing)

Finished the implementation and the tests for the Codec List message element. Also started the integration. ASSIGNMENT COMPLETE, ASSIGNMENT FAILURE and COMPLETE LAYER 3 INFORMATION can now handle the Codec List field.

See also branch: pmaier/aoip

The create functions of the messages which are relevant in the bsc role are now extended and we should be able to send AoIP messages by now. Also added encoding/decoding for two more elements: gsm0808_channel_type (needed for ASSIGNMENT REQUEST). And gsm0808_encrypt_info (needed for BSS_MAP_MSG_CIPHER_MODE_CMD). The encoding function of these two will be needed to for the create functions that generate the MSC messages. The decoding will replace the hacks in osmo_bsc_bssap.c.

We still lack the GSM0808_IE_CELL_IDENTIFIER_LIST element. Once we have that, we can implement the missing create functions for the MSC role.

We can now handle GSM0808_IE_CELL_IDENTIFIER_LIST, to the extend which we need (whole BSS, or by a list of LACs). All other schemes are not yet supported (our BSC can't handle them anyway), but we can upgrade any time, if needed.

We are also now ready to generate BSS_MAP_MSG_PAGING and BSS_MAP_MSG_CIPHER_MODE_CMD messages. We still miss the support for BSS_MAP_MSG_ASSIGMENT_RQST, but I think I will finish this one during the day tomorrow. After that we are ready to make some changes to the BSC code. In my opinion we should first get rid of the decoding hacks, since we now have proper decoding utilities, we should use them.

We now also can generate the assignment request. I have sent the patches now into the review process:

https://gerrit.osmocom.org/2177 gsm0808: Add utils for Speech Codec List and Speech Codec
https://gerrit.osmocom.org/2178 gsm0808: Add AoIP specific elements to gsm0808_create_... functions
https://gerrit.osmocom.org/2179 gsm0808: Add utils for Channel Type
https://gerrit.osmocom.org/2180 gsm0808: Add utils for Encryption Information
https://gerrit.osmocom.org/2181 gsm0808: Add utils for Cell Identifier List
https://gerrit.osmocom.org/2182 gsm0808: Add create functions for CIPHER MODE COMMAND
https://gerrit.osmocom.org/2183 gsm0808: Add create functions for BSS_MAP_MSG_PAGING
https://gerrit.osmocom.org/2184 gsm0808: Add create functions for BSS_MAP_MSG_ASSIGMENT_RQST

Started the integration of libosmo-sigtran into omso-bsc. To get a starting point I disabled the existing sccp-line code pathes and started to build up the interfaces for libosmo-sigtran next to it. When done, we can remove the no longer needed code.

There are some things where I am not sure if they can be removed, or if they have to work with the new code as well. There is this filter mechanism that seems to filter out unauthenticated connections. I think that will be handled directly by libosmo-sigtran in the future.

We also seem to have this strange feature that the BSC can be simultaniously connected to multipls MSC. To my understanding, this is not 100% standard conform. But since the infrastructure for this is now everywhere in the code. I think its easier when we just keep it.

For osmo-msc, I have started with some dummy MSC code to try out the BSSAP side on the MSC side. So far, the exchange of the RESET command is working fine. I can also make connections and can see the location update passing along together with CC and L3 Complete. It is not yet answered by my code, but It shows that most basic things are working. So we now should move on with integrating the dummy code into osmo-msc and see what happens when we forward the Location update into the MSC.

For osmo-bsc the most basic things should be done. We can connect to an msc and we can disconnect again. Connection contexts are created when the connection is opened and freed again when the connection closes. However. The mgcp side needs some attention now, but first some basic things like location update, imsi-detach and paging should work.

Started to integrate AoIP into osmo-msc. I have put my msc-dummy code into a_iface.c. The code does the reset handshake with the MSC and can receive Layer 3 complete messages. The code extracts the cell ID element and the Layer3 data element. I have tried to forward the code into the MSC, but I get a segfault (function bssmap_handle_l3_compl(), line rc = msc_compl_l3(conn, dtap_msg, 0);) here. Probably I am doing it wrong or something is not initialized properly.

Branches in openbsc.git:
pmaier/aoip_msc
pmaier/aoip_bsc

Apart from some AoIP messages that are still missing, the overall message passing between MSC and BSC works fine. Location update (without encryption!) works fine. I can attach phones and detach them again. Also the classmark change is already implemented.

The handling for the following messages is still missing:
BSS_MAP_MSG_CIPHER_MODE_REJECT
BSS_MAP_MSG_ASSIGMENT_FAILURE
BSS_MAP_MSG_SAPI_N_REJECT
BSS_MAP_MSG_CIPHER_MODE_COMPLETE (My guess is that I will have to detect the cipher mode command in the DTAP payload and then encapsulate it accordingly)
BSS_MAP_MSG_ASSIGMENT_COMPLETE

Branches in openbsc.git:
pmaier/aoip_msc
pmaier/aoip_bsc

Paging, Authentication and ciphering is working. Since paging is woring now, it is possible to send an SMS from one mobile to another.

The BSS_MAP_MSG_CIPHER_MODE_REJECT is parsed, no action is taken since I did not find the right hooks in the code where I could possibly deliver a cause code. All in all, this is a rare event. If encryption fails the whole call will fail too. Its probably enough to just print an error message?

So far the following is still missing:
BSS_MAP_MSG_SAPI_N_REJECT (should be simple)
BSS_MAP_MSG_ASSIGMENT_FAILURE
BSS_MAP_MSG_ASSIGMENT_COMPLETE (setting up a call without audio should work without mgcp)

The code also still uses the simple-client/simple-server. I might need some hints on how to configure the STP

The code now handles all BSSMAP messages that are relevant for us. However, the Assignment command is not complete yet. Currently the code sends a dummy assignment with some hardcoded parameters to the BSC. The assigment gets immediately rejedted with cause code 22 (no radio resource). This is expected. Next big task would be to get voice traffic going.

I have discussed the current status and the code with neels today. He will continue working on the A-Interface while I am on vacation. I have also updated my branches in openbsc.git:
pmaier/aoip_msc
pmaier/aoip_bsc

Status update:

• The BSC can now receive AoIP transport identifiers via the assignment command. The contained IP/Port is forwared via IPACC/RSL to the BTS. The BTS will assign an RX port and return that back to the BSC. The BSC will than communicate that port back to the MSC via another AoIP transport identifier in the assignment complete message. However, this must be changed later. The BSC will get its own private MGCPGW. This will not change anything for the MSC side. The IP/Port negotiation and procedures will remain the same.

• The MSC currently sends the IP of its attached MGCPGW. Since the MSC performs a CRCX operation before sending the assignment command, an RX-Port is already allocated and the port number is known. That IP/Port pair is forwarded to the BSC. (conn->iu.mgcp_rtp_port_cn). The BSC will then return with the IP/Port pair where the BTS expects the RTP input (conn->iu.mgcp_rtp_port_ue). This does not work. I think I am using the wrong struct members here.

struct gsm_subscriber_connection {
[...]
    /* which Iu-CS connection, if any. */
    struct {
        struct ue_conn_ctx *ue_ctx;
        int integrity_protection;
        unsigned int mgcp_rtp_endpoint;
        uint16_t mgcp_rtp_port_ue;
        uint16_t mgcp_rtp_port_cn;
        uint8_t rab_id;
    } iu;
[...]
}

My biggest question is what are mgcp_rtp_port_ue and mgcp_rtp_port_cn for? Am I correct (probably not) that mgcp_rtp_port_cn is the RX port at the MGCP, where the BTS has to send its data?. Is mgcp_rtp_port_ue the RX port at the BTS where the MGCPGW has to send its RTP stream to?

The logic that currently works for 3G should work for 2G as well.

There is good news: Made a successful voice call. I will now clean the current state a bit up and push it. We also still have to give the BSC its own MGCP.

Current status can be found on branch: pmaier/aoip

Worked on the negotiation of the speech codec:

• The MSC now generates the mandatory channel type element, which contains the preferred air interface codecs, which were issued with the setup command before. The MSC uses the same input values to generate the speech codec list element also. This element is mandatory in an AoIP network and has to be consistant to the channel type element. Since we preferably avoid transcoding, we will almost never have a scenario where the speech codec on the air interface is different from what we transfer on the RTP stream in the IP-Backhaul. This means that the codec configuration we use in the speech codec element will be set to default values that match the (fixed) configuration on the air interface.

• The MSC checks if There is a preference for Halfrate. If Halfrate V1 is the only available Halfrate codec, it overwrites changes the preference to Fullrate.

• On the BSC side, the channel type element is evaluated against the codec-list preferences we preset via the VTY. The BSC will pick its prefered codec from the list offered by the MSC. If we are on an AoIP network, the BSC will also evaluate the speech codec element. It will try to find its prefered codec (with the default settings) there as well. Only if a match in both elements is found, the assignment will proceed. Otherwise it will be rejected.

• When the assignment is complete. The BSC will return the codec it has picked in the choosen channel element. When on an AoIP network, it will also attach a speech codec element, which reflects the standard codec configuration for the selected codec.

Now I do not know what to do with the choosen channel and the speech codec element that the BSC is returning to the MSC. As far as I understand we never really cared about that. As long has two compatible channels are connected the call should be successful. If not, we have two different codec settings and it will not work.

The current state can be found on pmaier/aoip

The MSC sided reset is now fully working (see also OS#76). Also both sides now keep track of their open SCCP connections and will close all of them if a reset is received. The MSC already uses the sccp-addressbook feature to have configurable SCCP addresses. This part is not pushed yet. I will push it as soon as I have the BSC side done as well. Othereise I think I will cause too much confusiuon (tester).

Now both sides support configuring the sccp addresses via VTY. Displaying/Writing the configuration works too. However, the NO-Commands will be a bit tricky as the connections related to the removed address must be properly shut down. For the MSC this schould be easy to maintain. For the BSC I don't know. The VTY adds the parameters, and so also the sccp addresses to a struct and adds that struct to a list. Then later in the code the list is iterated and the connections are started. We will see. Maybe we can untangle that.

On the MSC, we can now remove and add BSC connections while it is running. For the BSC I see multiple problems.

When the BSC is starting, it parses the config file. There are multiple options and while it goes through all the options it builds up struct bsc_msc_data and adds it to the mscs list in bsc_gsmnet->bsc_data->mscs. When done. The BSC goes through that list and starts up all the related connections.

We could untangle this, but then we need a trigger, that finally starts up the connection. Since we do have multiple VTY options, we do not know when the struct is ready. To get around this. We could have a final command in the node that does the startup for us. like conn-active true or so. However, this would be not so nice anyway. Another option would be to introduce VTY commands to stop and restart connections. Before are made, the connection is stopped, when done. The connections restarted again.

I had a chat with daniel about the problem. He says that there are also other VTY options that would cause problems when edited during runtime. All in all I think it is not all too problematic when the user has to restart the BSC when VTY changes are made.

Fixed the MSC side reset so that it does not need the VTY configuration anymore. As discussed, it immediately creates the bsc context and starts the reset procedure when it gets a message from the BSC the first time. This can be a connection attempt or a BSSAP RESET message. This works way better than I thought and saves all the hassel with the VTY.

The BSC side is mostly kept as it is. I renamed the calling/called address VTY commands int bsc-addr and msc-addr. We now enforce the usage of standard SSNs. Also did some code cleanups, in the BSC I have renamed all calling/called address variables into bsc_addr and msc_addr. We also do check if the addresses we use have at least a point-code (and an ssn, which is guraneed, but we might consider configurable SSNs in the future, so I check this as well).

The new state can be found on pmaier/aoip2 and is directly based on origin/aoip so that the pending changes can be merged into origin/aoip by neels.

Since the we are done with the core parts of AoIP we should split new things up in separate tasks, like we already did with #2322, #2348 and others.