MME Changes in Release 21 - Cisco · MME Changes in Release 21...

MME Changes in Release 21

This chapter identifies features and functionality added to, modified for, or deprecated from the MME inStarOS 21 software releases.

• MME Enhancements for 21.0, page 1

MME Enhancements for 21.0This section identifies all of the MME enhancements included in this release:

Feature Changes - new or modified features or behavior changes. For details, refer to theMMEAdministrationGuide for this release.

CommandChanges - changes to any of the CLI command syntax. For details, refer to theASR 5x00 CommandLine Interface Reference for this release.

Performance Indicator Changes - new, modified, and deprecated bulk statistics, disconnect reasons, countersand/or fields in new or modified schema and/or show command output. For detailed information on the showcommands, refer to the Statistics and Counters Reference for this release. For detailed information on thecounters and disconnect reasons, refer to the BulkstatStatistics_documentation.xls spreadsheet that isincluded as part of the software companion package for this release.

This release includes enhancements that are applicable to multiple products. The following lists the variousmulti-product enhancements sections, some of which might include content applicable to your MME.

Important

• AAA Enhancements

• CF Enhancements

• ECS Enhancements

• Firewall Enhancements

• GTPP Enhancements

• Lawful Intercept Enhancements

• NAT Enhancements

Release Change Reference, StarOS Release 21 1

• SNMP MIB Enhancements

• System and Platform Enhancements

Release 21.0 introduces a number of security enhancements whichmay affect existing system deployments.Refer to the System Changes chapter in this guide for detailed information.

Important

eDRX Support on the MMECSCuz02521 - eDRX support on MME

Related CDETS ID: CSCva41634

This feature describes the Extended Discontinuous Reception support on the MME in the following sections:

Feature DescriptionThe Extended Discontinuous Reception (eDRX) feature allows IoT devices to remain inactive for longerperiods. This feature allows the device to connect to a network on a need basis – the device can remain inactiveor in sleep mode for minutes, hours or even days, thus increasing the battery life of the device.

Extended DRX cycles provide UEs longer inactive periods between reading, paging or controlling channels.

The Extended DRX feature is license controlled. Contact your Cisco Account or Support representative forinformation on how to obtain a license.

How eDRX WorksIn order to use the eDRX feature, the UE requests eDRX parameters during ATTACH and TAU procedures.

Based on the configuration, the MME may accept or reject the UE’s request to enable the eDRX feature. Ifthe MME accepts the eDRX request, different values of the eDRX parameters are provided based on operatorpolicies, apart from the parameters requested by the UE.

eDRX Parameters

AHyper-SFN (H-SFN) frame structure is defined for regular idle mode DRX. Each H-SFN value correspondsto a legacy SFN cycle comprised of 1024 radio frames (10.24 seconds). The eDRX consists of values that area power of 2, ranging from 5.12 seconds (i.e. 5.12, 10.24, 20.48 seconds and so on) up to a maximum of2621.44 seconds (43.69 minutes). When EDRX is enabled for a UE, the UE is reachable for paging in specificPaging Hyperframes (PH), which is a specific set of H-SFN values. The PH computation is a formula that isfunction of the EDRX cycle, and a UE specific identifier. This value can be computed at all UEs and MMEswithout need for signalling. The MME includes the extended idle mode DRX cycle length in paging messageto assist the eNodeB in paging the UE.

The MME also assigns a Paging Time Window length, and provides this value to the UE during attach/TAUprocedures together with the extended idle mode DRX cycle length. The UE first paging occasion is withinthe Paging Hyperframe. The UE is assumed reachable for paging for an additional Paging Time Window

Release Change Reference, StarOS Release 212

MME Changes in Release 21eDRX Support on the MME

length after first paging occasion. After the Paging Time Window length, the MME considers the UEunreachable for paging until the next Paging Hyperfame.

Loose Hyper SFN Synchronization

In order for the UE to be paged at roughly similar time, the H-SFN of all eNodeBs and MMEs should beloosely synchronized.

Each eNodeB and MME synchronizes internally the H-SFN counter so that the start of H-SFN=0 coincideswith a preconfigured time. It is assumed that eNodeBs and MMEs are able to use the same H-SFN value withaccuracy in the order of legacy DRX cycle lengths, e.g. 1 to 2 seconds. There is no need for synchronizationat SFN level.

There is no signalling between network nodes required to achieve this level of loose H-SFN synchronization.

Paging and Paging Retransmission Strategy

When the MME receives trigger for paging and the UE is reachable for paging, the MME sends the pagingrequest. If the UE is not reachable for paging, then theMME pages the UE just before the next paging occasion.

The MME determines the Paging Time Window length based on paging retransmission strategy, and uses itto execute the retransmission scheme.

Standards ComplianceThe eDRX feature complies with the following standards:

• 3GPP TS 23.682 version 13.4.0, Architecture enhancements to facilitate communications with packetdata networks and applications (Release 13)

• 3GPP TS 24.302 version 13.5.0, Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS);Stage 3 (Release 13)

• 3GPP TS 23.401 version 13.5.0, General Packet Radio Service (GPRS) enhancements for EvolvedUniversal Terrestrial Radio Access Network (E-UTRAN) access.

• 3GPP TS 29.274 version 13.5.0, 3GPP Evolved Packet System (EPS); Evolved General Packet RadioService (GPRS) Tunneling Protocol for Control plane (GTPv2-C); Stage 3

Limitations and RestrictionsThe eDRX feature is compatible only with IoT devices. It is not available for all Mobile Stations (MS), thatis, only thoseMSs and their respective Base Service Stations (BSS) that have the extended coverage parametersare supported by the SGSN.

Configuring eDRX on the MME

Enabling eDRX on MME

The following CLI configuration enables the eDRX feature on the SGSN. The configuration also providesthe following:



• Accept eDRX parameters: Paging Time Window (PTW) and eDRX cycle length value, from the UE.

• Configure PTW and eDRX cycle length value.

The above configuration is available under the Call Control Profile Configuration mode.

configurecontext context_name

mme-service service_nameedrx { ue-requested | ptw ptw_value edrx-cycle cycle_length_value [ dl-buf-duration [

packet-count packet_count_value] ] }

remove edrxend

Notes:

• remove disables the eDRX configuration on the MME.

• edrx configures Extended Discontinuous Reception parameters.

• ue-requested specifies the UE requested values of the Paging Time Window and the eDRX CycleLength are accepted.

• ptwSpecifies the Paging Time Window (PTW) value received from the UE in the Attach REquest/TAURequest message. The PTW value is an integer ranging from 0 to 20 seconds.

• edrx-cycle Specifies the accepted UE requested values of the Paging TimeWindow and the eDRXCycleLength.

• MME sends Downlink Buffer Duration IE in Downlink Data Notification Acknowledgment messageto the gateway when MME is unable to page the UE.

• MME sendsDownlink Buffering Suggested Packet Count value to gateway in DownlinkData NotificationAcknowledgment message when MME is unable to page UE. the packet count is an integer that rangesfrom 0 to 65535.

Verifying eDRX on the MME

The below given command displays the following new fields that are added to support the eDRX feature:

show call-control-profile full name <cp-name>Extended DRX:

Paging Time Window : 10 SecondseDRX Cycle Length : 512 SecondsDownlink Buffer Duration in DDN Ack : EnabledDL Buffering Suggested Packet count in DDN Ack : 10

Configuring Hyper SFN Synchronization

The following CLI allows to configure the Hyper SFN Synchronization start time.


mme-service service_nameedrx hsfn-start UTC_Timeno edrx hsfn-startend

Notes:



• The no option disables the H-SFN synchronization time configuration.

• The edrx command specifies the Extended Discontinuous Reception H-SFN start time.

• The hsfn-start keyword specifies the UTC Time at which H-SFN=0 starts. The time should be enteredin the UTC Time format as follows: YYYY:MM:DD:hh:mm:ss. For example: 2016:03:01:12:34:56.

Verifying H-SFN Synchronization

The below given command displays the following new fields that are added to verify H-SFN Synchronization:

show mme-service full <service-name>Extended DRX:

H-SFN Start: 2016:03:01:12:34:56

Monitoring and Troubleshooting eDRX

eDRX Show Command(s) and /or Outputs

This section provides information regarding show commands and their outputs for the eDRX feature.

show mme-service statistics

• EDRX Subscribers

◦Attached Cells

◦DDN Rejects

Notes:

• Attached Calls: Displays the number of attached subscribers for which EDRX is enabled.

• DDN Rejects: Displays the number of DDNs rejected when EDRX subscribers cannot be paged (UE isout of the paging window)

show egtpc statistics verbose

Executing the above command displays the following fields for this feature:

• Create Bearer Denied

• Create Bearer Denied TX

◦UE not reachable due to PSM

• Update Bearer Denied

• Update Bearer Denied TX

◦UE not reachable due to PSM



Bulk StatisticsFunctional descriptions, triggers and statistic type are defined for each of the bulk statistics listed below inthe Statistics and Counters Reference

• %attached-edrx-subscriber%

• %ddn-rejects-edrx%

Handling of 'X2-handover-triggered (35)'CSCva88886 - VoLTE call failure due to failed UE Ctx Modification

Feature Changes

Previous Behavior:TAU is rejected when an UE Context Modification Failure received with cause 35,"X2-handover-triggered (35)" for UE Context Modification Request.

New Behavior:TAU is not rejected when an UE Context Modification Failure received with cause 35,"X2-handover-triggered (35)" for UE Context Modification Request. Instead an UE Context Modification isre-sent after X2-HO completion or after "5" seconds have elapsed.

Customer Impact: An improved TAU success rate is observed.

Immediate Response Through IDACSCuv87612 - MME to reply to IDR immediately if UE location is learned *recently*

MME's Immediate response through IDA is discussed in the following sections:

MME's Immediate Response Through IDAIn Release 21.0 the MME responds to the IDR messages immediately with the cached location information,if the request is received within a configured amount of time. Earlier, when the MME received an IDR requestfor the current location of the UE, it sends a query to the eNodeB to acquire the location information of theUE, though MME had the location information available in it's cache memory.

Now, based on a configurable timer under mme-service configuration, the location information, that is, ECGIand TAI of the UE, available in the MME cache memory, is sent immediately in the IDA message. Thislocation information is sent only if the configured timer has not expired. The eNodeB is not queried with anymessages if the location information is available in the MME.

If both flags 'EPS Location Information' and 'Current Location Request' are received in the IDR, the MMEimmediately sends the cached location information through the IDA, if the configured timer has not expired.

This specific functionality of MME to respond immediately to the incoming IDR is license controlled. Contactyour Cisco Account or Support representative for information on how to obtain a license.


MME Changes in Release 21Handling of 'X2-handover-triggered (35)'

Configuring Location Validation Timer for IDA

loc-validity-time

This command is used to configure a timer value, with which the location information of the UE is sentimmediately through the IDA message. If the current location is not learned before expiry, because there isno paging response or location reporting control from the eNB, the MME sends the IDA with the last-knownlocation upon expiry of this timer.


mme-service service_name[ no ] isda loc-validity-timeout timer_valueend

Notes:

• no disables the location validity configuration.

• timer_value specifies the amount of time in seconds. The timer is an integer value that ranges from 1 to1000 seconds.

• isda command specifies/selects the Insert Subscriber Data Answer sent to the HSS.

• loc-validity-time command specifies the expiry time for the age of the UE's location information. Duringthis time, if the EPS Location Information with current location is requested in the ISDR, theMME doesnot process a location procedure with the eNodeB, but sends the location information from the cache.

Verifying the Precedence Configuration

The show lte-policy paging-map name map_name command allows you to see the precedence informationconfigured, for example:asr5000# show lte-policy paging-map name pm1=====================================================================Paging Map : pm1

=====================================================================Precedence 2 : Signaling-IDR Paging is performed as per paging-profile pm1

--------------------------------------------------------------------

Monitoring and Troubleshooting

show mme-service all

On execution of the above command, the following fields are displayed:Service Name : mmesvc---------------ISDA Gaurd Timeout : 10sISDA Location Availability : 10sMobile Reachable Timeout : 3480s---------------

show hss-peer-service statistics

In support of the new "State/Location Information Retrieval" flag functionality, counters have been added tothe output generated by the show hss-peer-service statistics command :


MME Changes in Release 21Immediate Response Through IDA

• Asynchronous Message Stats:

• Asynchronous ISDR Req

• Asynchronous ISDA

• Aynchronous ISDA Dropped

Bulk Statistics

The following bulk statistics have been added to the HSS Schema to track the location information responseto the IDR:

• msg-isdr-curr-loc

• msg-isda-cached-location

ISDA T-ADS ResponseCSCuy96572 - Inquiry on MME providing incorrect ISD T-ADS response

Previous Behavior: If an Insert-Subscriber-Data-Request (ISDR) is received with IDR-FLAG [ indicatingthe T-ADS Data Request ] by the MME when TAU/RAU/S1-HO to peer SGSN/MME is in progress, theMME sends the T-ADS Information in the Insert-Subscriber-Data-Answer (ISDA).

New Behavior: Now, if an Insert-Subscriber-Data-Request (ISDR) is received with IDR-FLAG [ indicatingthe T-ADS Data Request ] by the MME when TAU/RAU/S1-HO to peer SGSN/MME is in progress, theMME does not send the T-ADS Information in the Insert-Subscriber-Data-Answer (ISDA).

The MME does not send a T-ADS Information during the following procedures:

• 4G to 3G RAU (Gn and S4)

• TAU to peer MME

• S1-HO to 3G (Gn and S4)

• S1-HO to peer MME

MME Scaling on DPC2 to 2xDPCCSCuz04154 - MME Scaling on DPC2 to 2xDPC

Feature Changes

This feature enhancement provides improved CEPS (Call Events Per Second) and session capacity utilizationfor MME/SGSN on the ASR5500 DPC2 platform. It is observed that the current MME/SGSN deploymentslimit the maximum session/subscriber capacity utilization as the CPU reaches its maximum threshold forsome proclets though sufficient memory is available in the system and in the proclet for additionalsessions/subscribers. With this enhancement, the session utilization capacity is doubled (2X) on the ASR5500DPC2 platform for a specific call model.

This feature has increased the limits for the following MME/SGSN specific proclets on ASR5500 DPC2platform:


MME Changes in Release 21ISDA T-ADS Response

• The maximum number of MME managers per chassis has been increased to "48" on ASR5500 DPC2platform.

• The maximum number of MMEmanagers per Non-Demux card has been increased to "8" on ASR5500DPC2 platform.

• The maximum number of IMSI managers per Demux card has been increased to "8" on ASR5500 DPC2platform.

For detailed information see,UDPC2 Support for MME/SGSN feature chapter in the SGSN andMMEAdmin.guides.

Negotiated QoS for Operator Defined QCICSCva50039 - Negotiated QOS not sent in Activate Default Request for non-std QCI

Previous Behavior: Earlier, when only Standard QCI was available, there was standard mapping proceduresbetween Standard QCI and the 3G QoS parameters. The Negotiated QoS parameters was sent in the IE in theATTACH accept message, which also included the standard mapped QoS parameters. Negotiated QoSparameters were not sent in the ATTACH accept (Activate Default bearer Request) message for an OperatorDefined QCI, though the QCI value was accepted in the QoS Profile configuration.

New Behavior: From Release 21 onwards, the standard mapped QoS parameters received from the QoSProfile and the Bearer Control Profile will be sent in the ATTACH accept (Activate Default bearer Request)message when an Operator Defined QCI is received in the subscription data, and when a Bearer Control Profileconfiguration exists for the received Operator Defined QCI.

Validation of Mandatory IEs in LCI and OCI IECSCuz96496 - R12 Overload: Not rejecting attach if mandatory IE's missing in PGW OCI.

Feature Changes

Previous Behavior:Request or response messages that contain PGW OCI IE are processed successfullythough mandatory IE's in PGWOCI IE are missing. Validation check for presence of mandatory IEs is absentfor LCI and OCI group IE.

New Behavior: A validation check has been added for mandatory IEs in LCI and OCI IE. As a result requestand messages that contain PGW OCI IE but missing mandatory IEs are rejected or dropped.

Overload Control Information Display CorrectedCSCuz98383 - R12 Overload: MME not invalidating OCI after Period of Validity expiry

Feature Changes

Previous Behavior: After the OCI (Overload Control Information) validity expires, the following showcommands incorrectly display the OCI value:

• show egtpc peers

• show egtpc peers sessmgr


MME Changes in Release 21Negotiated QoS for Operator Defined QCI

• show egtpc peers wf1

New Behavior: The show commands listed above have been corrected, and after OCI validity expires theOCI value is not displayed.

Power Saving Mode (PSM) in UEsCSCuz02518 - Power Saving Mode support on MME

This feature describes the support for Power Saving Mode (PSM) in UEs in the following sections:

Feature DescriptionInternet of Things (IoT) is a computing concept where everyday objects have internet connectivity and theycan collect and exchange data. IoT is a network which can comprise of a wide variety of physical devices,vehicles, buildings, and any other device/object used in our daily lives. They are embedded with sensors,software and network connectivity which help them communicate with other devices in the network and canbe controlled remotely thus increasing efficiency, accuracy and economic benefit. Any device/object whichhas to be a part of the IoT network must have:

• Long battery life

• Low device cost

• Low deployment cost

• Full network coverage

• Support to connect to large number of devices

Power SavingMode (PSM) was introduced in 3GPP Release 12, to improve device battery life of IOT devices.The most significant benefit of this feature is the UE has more control in terms of power management requiredfor its application. There are a wide range of IoT applications where flexibility of the UE to manage its poweris very important and also implementation of PSM can prevent network congestion. The timers of all thedevices can be managed using PSM, and the wake-up periods can be adjusted to be offset as much as possible.This way all of the devices will not wake at the same time and attempt to access the network. The PSM modeis similar to power-off but the UE remains registered on the network.

The UE activates PSM by including two timer values in the Attach or Tracking Area Update (TAU). The firsttimer is the T3324, which defines the time the UE stays active after idle mode following the Attach or TAUprocedure. The second timer is an extended T3412 which defines the extended time for an UE to send periodicTAU.

Power Saving Mode Timers

T3324 Active Timer

The UE requests for a T3324 Active Timer value during Attach and TAU procedures. The MME allocatesthe T3324 value to the UE. The T3324 active timer determines the duration during which the device remainsreachable for mobile terminated transaction on transition from connected to idle mode. The device starts theactive timer when it moves from connected to idle mode and when the active timer expires, the device movesto Power Saving Mode. The MME takes the UE requested value and MME local configuration into accountfor determining the Active Timer value. TheMME includes the T3324 value IE in the ATTACHACCEPT/TAUACCEPT message only if the T3324 value IE was included in the ATTACH REQUEST/TAU REQUEST


MME Changes in Release 21Power Saving Mode (PSM) in UEs

message. A UE using PSM is available for mobile terminating services only for the period of an Active Timeafter a mobile originated event like data transfer or signaling for example after a periodic TAU/RAU procedure.

The MME allows a value of '0' for the T3324 timer. In this case the UE enters the Power Saving Modeimmediately.

T3412 Extended Timer

The T3412 timer is also referred to as the periodic Tracking Area Update (TAU) timer. Periodic tracking areaupdating is used to periodically notify the availability of the UE to the network. The procedure is controlledin the UE by the periodic tracking area update timer (timer T3412). The value of timer T3412 is sent by thenetwork to the UE in the ATTACH ACCEPT message and can be sent in the TRACKING AREA UPDATEACCEPT message. The UE shall apply this value in all tracking areas of the list of tracking areas assigned tothe UE, until a new value is received. A longer periodic TAU timer is possible using T3412 extended timer.When the UE includes the T3324 value IE and the UE indicates support for extended periodic timer value inthe MS network feature support IE, it may also include the T3412 extended value IE. Apart from the valuerequested by the UE, the MME verifies the local configuration into account while selecting a value for theT3412 extended timer. When the MME includes the T3412 extended value IE in the ATTACH ACCEPTmessage or TRACKING AREA UPDATE ACCEPT message , the MME uses timer T3412 extended valueIE as the value of timer T3412.

Other Feature Enhancements

The MME allows a value of "0" for timer T3324 (Which implies the UE enters Power Saving Modeimmediately).

MME may also include Downlink buffer duration and "Downlink suggested packet count" in DDN ACK ifit is configured.

The following new flags are introduced as part of this feature; these flags are supported in GTPCv2 IndicationIE:

• Pending Network Initiated PDN Connection Signaling Indication (PNSI): The source MME supportssending of PNSI flag in GTPCv2 Indication IE of Context response.

• UEAvailable for Signaling Indication (UASI): TheMME supports sending of the UASI flag in GTPCv2Indication IE of Create Session Request and Modify Bearer Request.

• Delay Tolerant Connection Indication (DTCI): The MME supports receiving the DTCI flag in CreateSession Response from the SGW. The MME supports receiving of the DTCI flag in Context Responseand Forward Relocation Request from peer MME or S4-SGSN.

The MME rejects CBR/UBR when PPF is False. The cause "UE is temporarily not reachable due to powersaving" is sent in the response by the MME if the corresponding PDN was marked "Delay tolerant" by PGW.

How It WorksA subscriber is PSM enabled only when:

• UE sends T3324 timer in ATTACH/TAU.

• Power Saving Mode is enabled in configuration by providing T3324 active and T 3412 extended timersor by configuring "UE requested" timer values.

A CLI-based configuration is provided to configure the T 3324 active and T 3412 extended timers. The CLIprovides an option to either accept UE requested values or MME configured values for these timers. The CLI



is also used to configure either to send or not send the Downlink Buffer Duration in DDN Ack, the DDN AckOptional IE "Downlink Suggested Packet Count" can also be configured. When the PSM CLI configurationis enabled, the MME accepts the use of PSM and a UE requested value of T3324 is received in Attach/TAUrequest. If the CLI is configured to accept UE requested values of timers and if T3412 extended timer is notreceived from the UE along with T3324 in Attach/TAU request, then MME uses the same value of T3412timer available inMME service configuration. The values of T3324 and T3412 timers extended are determinedbased on the configuration. If the MME has allocated an Active Time (T3324) to the UE, then the MME startsthe Active timer with the value of T3324 whenever the UE enters IDLEmode. If this timer expires, thenMMEclears the PPF (Paging Proceed Flag). When the PPF is clear, the MME does not page the UE on receiving aDownlink Data Notificationmessage and sends a Downlink Data NotificationAckmessage with cause "Unableto page UE" to the Serving GW with DL buffering duration and DL suggested packet count IEs as per theoperator configuration. TheMME rejects network initiated PDN connections during power saving mode. TheMME sends the cause "UE is temporarily not reachable due to power saving" if the corresponding PDN wasmarked Delay Tolerant (DTCI flag set) by PGW. The source MME sets the PNSI flag in Context Responseif there are any pending network initiated PDN connections (For example, Create Bearer Request/UpdateBearer Request). The MME sets the UASI flag in the Create Session Request or Modify Bearer Requestmessage when UE is available for end-to-end signaling. The UE is in PSM until a mobile originated event(for example periodic RAU/TAU, mobile originated data or detach) requires the UE to begin any proceduretowards the MME.

LimitationsUE Power Saving Mode is not supported in the CS domain on the network side. A UE that uses mobileterminated IMS or CS services other than SMS should not use PSM as neither IMS nor the CS domain providesupport for mobile terminated CS voice or IMS services to UEs that are in PSM.

Standards ComplianceThe Power Saving Mode feature complies with the following standards:

• 3GPP TS 24.301 Release 13.5.0

• 3GPP TS 23.401 Release 13.5.0

• 3GPP TS 29.274 Release 13.5.0

Configuring UE Power Saving ModeThis section describes how to configure the UE Power Saving Mode feature. The following CLI commandis introduced in the Call Control Profile to configure the UE Power Saving Mode parameters.

configurecall-control-profile profile_name[remove] psm {ue-requested [dl-buf-duration [packet-count packet_value ]]| t3324-timeout t3324_value

t3412-extended-timeout t3412_ext_value [dl-buf-duration [packet-count packet_value ]]}exit

Notes:

• The operator can use the keyword ue-requested, when UE requested values for Active and ExtendedPeriodic timers are to be accepted.



• The keyword dl-buf-duration is used to send Downlink Buffer Duration in DDN ACK when unableto page UE. If this keyword is not configured buffer duration will not be sent in DDN-ACK. By defaultbuffer duration is not sent in DDN ACK.

• The keyword packet-count is used to send 'DL Buffering Suggested Packet Count' in DDN ACK whenunable to page UE. The packet count value is an integer value from “0” up to “65535”.

• The keyword t3324-timeout is used to configure the T3324 active timer value. The T3324 active timeris an integer value in the range 0 up to 11160 seconds.

• The keyword t3412-timeout is used to configure the T3412 Extended timer value. The T3412 extendedtimer is an integer value in the range 0 up to 35712000 seconds.

• This command is not enabled by default.

• The keyword remove is used to disable UE power saving mode.

Monitoring and TroubleshootingThis section provides information on how to monitor the UE Power Saving Mode feature and to determinethat it is working correctly.

Show Command(s) and/or Outputs

This section provides information regarding show commands and/or their outputs updated in support of theUE Power Saving Mode feature.

The show commands in this section are available in support of this feature:

show call-control-profile full name

The PSM parameters are added to this show command:

• UE Power Saving Mode: This section displays all the PSM related parameters.

• T3324 Timeout: Displays the T3324 timer value in seconds.

• T3412 Extended Timeout: Displays the T3412 extended timer value in seconds.

• Downlink Buffer Duration in DDN ACK: Displays if Downlink Buffer Duration in DDN ACK is eitherenabled or disabled.

• DLBuffering Suggested Packet Count in DDNACK: Displays the DL buffering suggested packet countin DDN ACK.

show mme-service session all

The following new parameters are added to this show command:

• UE Reachability Timer (PSM UE)

• T3412 Extended Timer



These timers are calculated based on operator configuration in the psm command under theCall-Control-Profile configuration mode.

Note

show mme-service statistics

The following new parameters are added to this show command:

• PSM Subscribers: Displays information related to PSM subscribers.

• Attached Calls: Displays the number of attached subscribers for whom PSM is enabled.

• DDN Rejects: Displays the number of DDN rejects that have occurred for PSM enabled subscribers. ADownlink Data Notification (DDN) is rejected when an UE is in power saving mode.

show egtpc statistics verbose

The following new parameter is added to this show command:

• UE not reachable due to PSM

The Create Bearer Request and Update Bearer Request are rejected when the UE is in Power Saving Mode.TheMMEsends the cause "EGTP_CAUSE_UE_TEMP_NOT_REACHABLE_DUE_TO_POWER_SAVING"in the reject message if that PDN is marked "Delay Tolerant" by PGW (DTCI flag enabled in PDNConnectionIndication IE of Create Session Response). Otherwise the MME sends the cause"EGTP_CAUSE_UNABLE_TO_PAGE_UE" to SGW in CBR/UBR Reject.

UE Power Saving Mode Bulk Statistics

The following statistics are included in the MME Schema in support of the UE Power Saving Mode feature:

• attached-psm-subscriber

• ddn-rejects-psm

SGW Blacklisting on the MMECSCuz10491 - MME Blacklisting of SGW

This chapter describes howMME blacklists un-accessible and un-responsive SGWs in the following sections:

Feature DescriptionThe SGW Blacklisting is a proprietary feature of StarOS. In this feature, the MME blacklists un-accessibleor un-responsive SGWs for a configured time. The MME does not select these blacklisted SGWs during anyprocedures that requires SGW selection so that there is minimal latency during the procedures. SGWBlacklisting is supported for both Static and Dynamic IP addresses.

To support SGW blacklisting, a new CLI sgw-blacklist is added under theMME Service Configuration mode.When this feature is enabled, SGW blacklisting takes place using the following methods in the MME:


MME Changes in Release 21SGW Blacklisting on the MME

• Node Level Blacklisting

• Session Manager Level Blacklisting

A valid license key is required to enable SGW Blacklisting on the MME. Contact your Cisco Account orSupport Representative for information on how to obtain a license.

How It WorksOn identifying an unreachable SGW, the SGW is blacklisted for a configured amount of time. The show CLIdiscussed in theMonitoring and Troubleshooting section displays the expiry timestamp of this SGW, indicatingthe blacklisting duration. This feature is based on a per mme-service configuration, therefore a separate listto store blacklisted SGWs is created for every mme-service.

During the ATTACH, TAU and Handover procedures, the MME selects an SGW that is not blacklisted. Ifall SGWs are blacklisted, then the MME attempts to use one of the blacklisted SGWs instead of directlyrejecting the call. If the Create Session Response time expires, the call is rejected.

The blacklisted SGWs are completely removed from the MME based on the following configurationchanges/execution:

• If the sgw-blacklist configuration is removed – SGW blacklisting feature is disabled.

• If the sgw-blacklist configuration is reconfigured, that is, if the timeout or the msg-timeouts-per-minvalues are changed.

• If mme-service is stopped; a critical parameter is removed from its configuration.

• If the clear CLI is executed, refer to Monitoring and Troubleshooting section.

The MME does not remove the blacklisted SGWs based on any SGW initiated request/response message.Note

The following functionalities are also included for SGW blacklisting:

• Weight based load distribution with the available SGWs when some of the SGWs are blacklisted.

• Session manager recovery is added to recover node-level blacklisted SGWs.

SGW blacklisting takes place using the following methods in the MME:

Node Level Blacklisting

When no echo response is received from the SGW, a node-level path failure indication is sent to all SESSMGRs.

Based on the node-level path failure indication, the MME blacklists the SGW for the configured time andstores it as a node-level blacklisted type.

Session Manager Level Blacklisting

Along with node-level blacklisting, MME supports blacklisting of SGW based on Create Session Responsetimeout per SESSMGR instance. The Session Manager Level blacklisting is local to a specific SESSMGRinstance and its particular mme-service where the Create Session Response times out.

To avoid broadcasting among SESSMGRs, sessionmanager level blacklisting is not shared among SESSMGRs.



Along with “sgw-blacklist timeout” configuration, "msg-timeouts-per-min” configuration is configured, whichis only required for sgmr-level blacklisting. Instead of blacklisting an SGW in the first Create Session Responsetimeout, the MME blacklists an SGW if the number of Create Session Response timeouts within a minutereaches the configured msg-timeouts-per-minute value. For more information, refer to Configuring SGWBlacklisting on the MME section.

Configuring SGW Blacklisting on the MMEThe following CLI configures SGW blacklist timeout value, and the number of Create Session Responsetimeouts per minute to blacklist an SGW locally in a SESSMGR instance.

The configuration is provided under the MME Service Configuration mode.

configcontext context_name

mme-service service_name[ no ] sgw-blacklist timeout timer_valuemsg-timeouts-per-min number_of_timeoutsend

• no disables the SGW Blacklisting configuration.

• sgw-blacklist specifies the configurable parameters required for SGW blacklisting.

• timeout specifies the period of time the blacklisted SGW cannot be used for call procedures. The timeoutvalue is an integer ranging from 5 to 86400 seconds.

• msg-timeouts-per-min configures the number of message timeouts to wait, before blacklisting a SGWlocally in a session manager instance. Only Create Session Response timeout is considered. The numberof message is an integer ranging from 1 to 5000.

• By default, this configuration is not enabled.

Verifying SGW Blacklisting on the MME

The below given command displays the following new fields that are added to support the SGW Blacklistingfeature:

show mme-service sgw-blacklist [ mme-service-name name ] [ smgr-instance number ]

MME service name: mmesvcNode-level: 0 Instance-level: 1SGW IP : 192.168.20.2Blacklist type : Sessmgr-levelExpiry timestamp : Monday June 13 02:27:57 EDT 2016Blacklist time left : 777 seconds

Notes:

• sgw-blacklist displays information on blacklisted SGWs.

• mme-service-name displays node level blacklisted SGWs for a specified mme-service

• smgr-instance displays node-level and sessionmanager level blacklisted SGWs for a specific SESSMGRinstance.

• Blacklist Type can either be Node level or Sessmgr-level.

• If smgr-instance option is selected, both Node-level and Sessmgr-level blacklisted SGWs are displayed,otherwise only Node-Level blacklisted SGWs are displayed.



Monitoring and Troubleshooting SGW Blacklisting on the MME

SGW Blacklisting Show Command(s) and /or Outputs

This section provides information regarding show commands and their outputs for the SGW blacklistingfeature.

show mme-service name name


• SGW Blacklist Parameters

• Timeout

◦msg-timeouts-per-min

show mme-service statistics emm-only


SGW Selection:Blacklisted SGW chosen: 0

Notes:

• The SGW Selection specifies the number of times a blacklisted SGW is selected when all SGWs areblacklisted.

clear mme-service sgw-blacklist [ mme-service-name name ] [ sgw-ip ]

Executing the above command clears the selected SGW or all blacklisted SGWs from the system.

Notes:

• sgw-blacklist clears the blacklisted SGWs.

• mme-service-name clears the blacklisted SGWs that belong to a particular mme-service.

• sgw-ip clears the specified blacklisted SGW based on the IP address.

A trace level event ID: 147153 has been added for this feature to log when any SGW address is blacklisted.





Date post:	20-Nov-2020
Category:	Documents
Upload:	others
View:	3 times
Download:	0 times

MME Changes in Release 21 - Cisco · MME Changes in Release 21...

Documents