Cisco Cisco Packet Data Gateway (PDG) Nota De Lançamento
MME Changes in Release 15.0
MME Enhancements for January 31, 2014 ▀
Cisco ASR 5x00 Release Change Reference ▄
321
CSCuj49578 - sctp link not established with sctp-sack-period 0 in sctp-param-
template
Feature Changes
Configuration of SCTP Parameter Template sctp-sack-period
Previous Behavior: If the SCTP Parameter Template associated to the MME and SGs services has a sctp-sack-period
configured as 0, the SCTP stack would not get initialized for the MME and SGs services.
configured as 0, the SCTP stack would not get initialized for the MME and SGs services.
New Behavior: When the sack period is configured as 0 for the associated SCTP Parameter Template to MME and SGs
services, the sack period is now automatically configured as 10ms in order for the SCTP stack to be initialized.
services, the sack period is now automatically configured as 10ms in order for the SCTP stack to be initialized.
CSCuj77490 - MME Incomplete Suspend Response towards SGSN via Gn (gtp-
c v1)
Feature Changes
MME Response to SGSN Context Request with Suspend Header
Previous Behavior: When the MME received a valid GTPv1 suspend request, the SGSN Context Response would be
sent without a suspend header. As a result, the SGSN never sent the ACK to MME, and the MME would retry the
context response.
sent without a suspend header. As a result, the SGSN never sent the ACK to MME, and the MME would retry the
context response.
New Behavior: On receiving a GTPv1 context request with a suspend header, the MME now sends the SGSN Context
Response with the complete “SGSN Context Response” with cause “Requested Accepted” (OK) and “Next Extension
Header” of type “Suspend Response” (NOT OK). The message is sent only once on the Gn interface (and not retried).
Response with the complete “SGSN Context Response” with cause “Requested Accepted” (OK) and “Next Extension
Header” of type “Suspend Response” (NOT OK). The message is sent only once on the Gn interface (and not retried).
CSCul43064 - IE 95/94 should not be included in case X2HO w/out SGW change
Feature Changes
S1AP Protocol Change During X2 Handover with no S-GW Relocation
Previous Behavior: During an X2 handover, the MME would always include all successfully switched bearers in the E-
RAB To Be Switched in Uplink List IE of a Path Switch Request Acknowledge message, regardless of whether the
uplink tunnel endpoint changed or not. However, there is at least one eNodeB implementation that takes the presence of
the IE to mean that S-GW relocation is taking place, regardless of the contents of the IE, and if the eNodeB is not
licensed for S-GW relocation, it will drop the connection if the IE is present. This results in calls always going idle
immediately following an X2 handover with no S-GW relocation.
RAB To Be Switched in Uplink List IE of a Path Switch Request Acknowledge message, regardless of whether the
uplink tunnel endpoint changed or not. However, there is at least one eNodeB implementation that takes the presence of
the IE to mean that S-GW relocation is taking place, regardless of the contents of the IE, and if the eNodeB is not
licensed for S-GW relocation, it will drop the connection if the IE is present. This results in calls always going idle
immediately following an X2 handover with no S-GW relocation.
New Behavior: The MME now includes the E-RAB To Be Switched in Uplink List IE of a Path Switch Request Ack
message when X2 handover with S-GW relocation is taking place. During an X2 handover with no S-GW relocation,
the IE will not be present.
message when X2 handover with S-GW relocation is taking place. During an X2 handover with no S-GW relocation,
the IE will not be present.
Customer Impact: X2 handovers with no S-GW relocation would not work with certain eNodeB implementations not
licensed for S-GW relocation, because they assume that presence of the IE implies S-GW relocation. Also note that, if
licensed for S-GW relocation, because they assume that presence of the IE implies S-GW relocation. Also note that, if