TFT Handling for WiFi Handovers
In 4G and 5G deployment, the three-way audio or video multiparty call conference, and RCS message use cases, PGW-C ends up having more than four filters (it can go upto max 16 filters) for both UL and DL direction. SMF includes “EPS Bearer Level Traffic Flow Template (Bearer TFT)” is included in the GTPv2 CBReq/UBReq of BearerContextList. CBReq/UBReq carry maximum of 4 TFTs per bearer.
In case of three-way Audio/Video and multiparty call-conference, PCF tries to push the pccRules by adding different subscriber TFTs in multiple “N7 Policy Notify Req” messages. PGW-C handles the received “N7 Update Notify Req” in dedicated bearer establishment or update towards WiFi or LTE by initiating GTPv2 CBReq or UBReq messages. SMF accommodates the received SDF Filters in TFT as it never crosses more than 256 Bytes (4 TFTs).
Note | PGW-C don’t support more than 4TFTs received from PCF “N7 Policy Notify Req”. |
PCF keeps pushing multiple pccRules for same bearer by sending “N7 Policy Notify Req” and over the period SMF ends up having 12-16 filters for case of multiparty call.
When subscriber moves from LTE to WiFi or WiFi to LTE or NR to WiFi Handover call-model cases, SMF first establishes default bearer creation as part of HO. SMF then tries to send out CBReq for Dedicated bearer establishment by accommodating all 16 filters in “EPS Bearer Level Traffic Flow Template (Bearer TFT)” of bearer context list of the subscriber and if it fails to encode because of these restrictions. The SMF sends out CBReq without “EPS Bearer Level Traffic Flow Template (Bearer TFT)” IE based on HO type, SGW/MME/ePDG rejects GTPv2 CBResp with Mandatory IE Incorrect with “TFT Semantic Errors”.
After receiving CBResp from SGW/ePDG, SMF doesn’t free up policy/charging resources for respective failed bearers and that leads to further stale entries on SMF and UPF which leads to system inconsistency for that subscriber with “EBI Mismatch – 408 Error Voice Call Failure WiFi HOs”.