Summary Data

A UE Relay Network comprises of multiple RAN and EPC nodes.

In some deployments, one MME can play the role of both User-UE MME and Relay-UE MME.

In a UE Relay network, System Architecture Evolution Gateways (SAEGWs) are deployed to play the role of combined ‘Relay-UE’s SGW/P-GW’. The SAEGWs are configured using only local-policy (that is no connection to PCRF).

As part of initial attach request from Relay Node UE, P-GW (in the aforementioned SAEGW) creates dedicated bearers (for example, QCI-1 for GBR and QCI5 for non-GBR) on top of the default bearer (for example, QCI6). This is done based on an appropriate local policy configuration which is described in later sections of this chapter.

When RF condition degrades, Relay Node UE loses the RRC connection to macro eNB. As a result, macro eNB initiates an S1 Release procedure with abnormal cause (for example, ‘Radio Connection with UE lost’ or ‘unspecified’). For these type of causes MME typically preserves non-GBR bearer and deletes GBR bearers. As a result, GBR bearers (for example, QCI-1 bearer) is deleted by the MME.

After the RRC Connection is re-established, the Relay Node UE sends Service Request to the MME. The MME sends Initial Context Setup Request to macro eNB to set up the previously preserved non-GBR bearers. The MME does not re-establish the GBR bearer since it was not preserved. As a result, Relay Node UE does not have the GBR bearer until a full re-attach procedure occurs.

Since GBR bearer is not re-established, the GBR traffic is carried over the default non-GBR bearer and the voice performance is degraded.

Using this feature SAEGW is able to re-establish the previously deleted GBR bearer when MME sends the Modify Bearer Request to re-establish the preserved the non-GBR bearers.

SAEGW re-establishes the previously deleted GBR bearer when MME sends the Modify Bearer Request, to re-establish the preserved non-GBR bearers.

This is achieved in SAEGW using two different mechanisms:

• Forwarding the Modify Bearer Request from SGW to P-GW

• P-GW to invoke local policy with a new event restore-bearers

Use the following configuraion to enable forced forwarding of Modify Bearer Request from S-GW to P-GW:

configure  
   context context_name 
      sgw-service service_name 
         enable-bearer-restore 
         end 

In S-GW service, whenever enable-bearer-restore option is set, modify bearer request is forwarded by S-GW to P-GW. It happens when the S-GW service is under SAEGW service.

For example:

config
   context ingress
     sgw-service sgw-service 
        enable-bearer-restore

Note

Without this CLI, S-GW only forwards the Modify Bearer Request message to P-GW if certain conditions are met. For example. RAT change, TimeZone change, ULI change, Handover indication flag, and so on as per 3GPP specifications. To avoid forwarding Modify Bearer Requests unnecessarily to P-GW, enable-bearer-restore should only be used when local policy is configured for restore-bearer event as described in next section.

A list of events supported under eventbase is enhanced with restore-bearers. This event is invoked when P-GW gets a Modify Bearer Request from S-GW. If local policy configuration has the restore-bearer event under eventbase then corresponding rules are applied.

Use the following configuration to re-establish missing bearers under local policy:

configure  
   local-policy-service local_policy_name 
      eventbase eventbase_name 
         [ no ] rule priority integer  
            event restore-bearers ruledef ruledef_name actiondef actiondef_name 
            end 

Following is an example for local policy configuration:

  local-policy-service local_policy
    ruledef apn_apn2
      condition priority 100 apn match apn2.com
    #exit

ruledef apn_apn1
      condition priority 100 apn match apn1.com
    #exit

    ruledef ded_bearer_creation_fail
      condition priority 100 apn match apn2.com
      condition priority 200 cause-code match 72 73 90 100 110
    #exit

    actiondef apn2_newcall
      action priority 100 allow-session
      action priority 500 activate-rule name apn2_dedicated_grp_of_rd
      action priority 600 activate-rule name apn2_qci1_dedicated_grp_of_rd
    #exit

    actiondef apn2_restore_bearer_config
      action priority 100 allow-session
      action priority 500 activate-rule name apn2_dedicated_grp_of_rd
      action priority 600 activate-rule name apn2_qci1_dedicated_grp_of_rd
    #exit

    actiondef apn2_retry_dedicated_bearer
      action priority 500 activate-rule name apn2_dedicated_grp_of_rd
      action priority 600 activate-rule name apn2_qci1_dedicated_grp_of_rd
      action priority 700 retry-count 4
      action priority 2000 allow-session
    #exit

actiondef apn1_newcall
      action priority 100 allow-session
    #exit

eventbase default
      rule priority 100 event new-call ruledef apn_apn1 actiondef apn1_newcall
      rule priority 200 event new-call ruledef apn_apn2 actiondef apn2_newcall
      rule priority 400 event rule-report-status ruledef ded_bearer_creation_fail actiondef apn2_retry_dedicated_bearer
      rule priority 600 event restore-bearers ruledef apn_apn2 actiondef apn2_restore_bearer_config
    #exit

The key point in the above configuration is that both "new-call" and "restore-bearers" events, the actiondefs comprise of same actions. As a result, any missing bearer (such as a QCI-1 GBR bearer) is established.

At the time of "new-call" event, both QCI-1 (GBR) and QCI-5 (non-GBR) bearers are created. At the time of "restore-bearer" event, local policy will return actions to create both QCI-1 and QCI-5 bearers but since QCI-5 bearer already exists (as it was preserved), only QCI-1 bearer is established.