Cellular Network Infrastructure » Core Network (CN) » OsmoMSC

dexter, can you take a look at this plz? Then let's talk about what needs to be changed, if any.

This is definetly on the list of the items that I will work on next. osmo-bsc_mgcp will be removed form osmo-msc and we will use osmo-mgw instead. There are indeed adjustments needed since osmo-msc is depending on the hacks of osmo-bsc_mgcp at the moment. When done it will be incompatible to osmo-bsc_mgcp and only work with osmo-mgw.

I have looked at the code now. We probably might consider to re-write the parts that control MGCP. Especially the loopback hack would work different now. (Simply create a loopback connection on the bts side and we should be good).

neels: Lets have a chat about this today.

As neels and me decided to re-implement the MGCP related parts with an osmo-fsm I have started doing that.

The FSM and the API around is outlined and partially implemented. The next step is to actually use it to see if it works as expected.

The FSM now seems to work fine. I did not test it with external mncc yet, but it should work. It also still must be tested with RANAP.

Patch is up for review: https://gerrit.osmocom.org/4980

The patch is still in the review process. There was some problem with the IU support I have overseen. Now this is also fixed and it now builds fine and the unit-tests all work.

The patch is now also tested against a setup with external MNCC. It turned out that the FSM missed a state. Before we used formulas to calculate the port on the RAN side, so we were not reliant on the ASSIGNMENT COMPLETE message. Now we are and we must wait until the assignment on the A-Interface side is complete. I expect a similar problem on the IuCS side. I did not test with IuCS yet. I need to get the nano3G BTS working first before I can test.

I have found the right location where the RTP / IP-Address of the NodeB becomes known. From there we just need to call msc_mgcp_ass_complete(). That should make it work again. Unfortunately the address information seems to be inside a nested ASN.1 encoded bitstring. I need some hints on how to pars this bitstring using our libraries.

Also have a look at: https://gerrit.osmocom.org/#/c/4980/13/src/libmsc/iucs_ranap.c

dexter wrote:

I have found the right location where the RTP / IP-Address of the NodeB becomes known. From there we just need to call msc_mgcp_ass_complete(). That should make it work again. Unfortunately the address information seems to be inside a nested ASN.1 encoded bitstring. I need some hints on how to pars this bitstring using our libraries.

Also have a look at: https://gerrit.osmocom.org/#/c/4980/13/src/libmsc/iucs_ranap.c

The code should work something like this:

static int decode_transp_layer_addr(BIT_STRING_t *in, uint32_t *ip_addr)
{                  
        implement reverse of new_transp_layer_addr() in ranap_msg_factory.c sort of like
        if (in->size != 160/8)
            ||in->buf[0] != 0x35
            || ...)
                return -EINVAL;
        memcpy(ip_addr, &in->buf[3], sizeof(*ip_addr));
        return 0;
}

static int iucs_rx_rab_assign(struct gsm_subscriber_connection *conn,
                              RANAP_RAB_SetupOrModifiedItemIEs_t *setup_ies)
{
        uint8_t rab_id; 
        RANAP_RAB_SetupOrModifiedItem_t *item = &setup_ies->raB_SetupOrModifiedItem;
        uint32_t ip_addr;
        uint32_t port; 

        rab_id = item->rAB_ID.buf[0];

        if (item->transportLayerAddress) {
                if (decode_transp_layer_addr(item->transportLayerAddress, &ip_addr)
                    error("fubar");
        }          

        if (item->iuTransportAssociation
            && item->iuTransportAssociation->present == RANAP_IuTransportAssociation_PR_bindingID) {
                port = asn1bitstr_to_u32(&item->iuTransportAssociation->choice.bindingId);
        } else {
                error("we need a port");
        }

        LOGP(DIUCS, LOGL_NOTICE,
             "Received RAB assignment event for %s rab_id=%hhd\n",
             vlr_subscr_name(conn->vsub), rab_id);

        return 0;
}

and it would make sense to implement the decode_transp_layer_addr in asn1helpers.c instead of locally, I guess. And move the new_transp_layer_addr() to asn1helpers.c too. Both with proper naming with respect to that public API.

It now also works for the nano3G, however external MNCC does not work yet because IuUP is not understood by the average PBX software.

The patch is still in review process: https://gerrit.osmocom.org/4980

There are two things to mention:

• We will get a more comfortable interface to the mgcp-client soon (see https://gerrit.osmocom.org/#/c/5881/) We might consider using it there too, this would simplify the implementation by some degrees.

• osmo-mgw now supports wildcarded CRCX, we should make use of this feature here.

pach merged. Let's make sure we iron out any kinks using more tests and making existing tests pass.