Cisco Cisco Packet Data Gateway (PDG)
MME Changes in Release 16
MME Enhancements for 16.4 ▀
Release Change Reference, StarOS Release 16 ▄
215
Performance Indicator Changes
MME Schema
Use of the “EPS QoS Not Accepted” reject cause code for bearer allocation failures, is tracked as a bulk statistic in the
MME schema:
MME schema:
esm-msgtx-brralloc-rej-eps-qos-not-accepted
show mme-service statistics
Use of the “EPS QoS Not Accepted” reject cause code for bearer allocation failures, is tracked with the following new
output counter generated by the
output counter generated by the
show mme-service statistics
command:
EPS QoS Not Accepted
CSCur27407 - NewConnectionsDisallowed SNMP trap firing a lot
Feature Changes
Processing SessMgr Location
Previous Behavior: When the SessMgr Location procedure failed during the MME's processing of a received request
(Attach / TAU request with FGUTI, GTPv2 Forward Relocation request, and GTPv1 Forward Relocation request), then
the MME rejects the request and sends a trap "MMENewConnectionsDisallowed" with reason "location of sessmgr
resource failed".
(Attach / TAU request with FGUTI, GTPv2 Forward Relocation request, and GTPv1 Forward Relocation request), then
the MME rejects the request and sends a trap "MMENewConnectionsDisallowed" with reason "location of sessmgr
resource failed".
New Behavior: If the SessMgr Location procedure fails during the MME's processing of a received request (Attach /
TAU request with FGUTI, GTPv2 Forward Relocation request, and GTPv1 Forward Relocation request), then a new
SessMgr is allocated, the request is processed, and the MME does not send the trap "MMENewConnectionsDisallowed"
with reason "location of sessmgr resource failed".
TAU request with FGUTI, GTPv2 Forward Relocation request, and GTPv1 Forward Relocation request), then a new
SessMgr is allocated, the request is processed, and the MME does not send the trap "MMENewConnectionsDisallowed"
with reason "location of sessmgr resource failed".
Customer Impact: Fewer requests rejected.
CSCur38243 - MME discards
EGTP_CREATE_INDIRECT_DATA_FORWARDING_TUNNEL_RSP
Feature Changes
Extended Validation Options for UL F-TEID during HO
Up Link - Fully qualified Tunnel End Point Identifier
Previous Behavior:
The MME did not accept ‘up link fully qualified tunnel end point identifier’ (UL F-TEID) in a Create Indirect
Data Forwarding Response and response was dropped).
The MME would only accept a UL F-TEID in a Create Indirect Data Forwarding Response from the S-GW if the
IE instance was 4 and the interface type was set at 28 (SGW GTP-U interface for UL data forwarding).