Hi,
I have a peculiar problem for the IMS APN traffic.
Having a problem where the UE initiates non SIP protocol messages like SSDP, BT-DHT protocols. Any idea why this can happen? Since there are no responses for these messages, the UEs are retrying and causing excessive traffic.
According to the available information.I will explain how the data flows between the network and the UE.Once the IMS default bearer is established that default Bearer is getting anchored in following places.Enodeb,PGW and PCSCF.Once the GRE tunnel is established EnodeB and PGW only remove and add the encapsulation headers so by the end of PGW.it will remove all encapsulations and packet will flow as normal IP packet.so if it is not sip then next hop routed will definetely drop that packet.or lets say if it reaches PCSCF it will be definetely dropped by PCSCF.Remember IMS default Bearer is Non GBR one .which means it is not a gurenteed bit rate tunnel so when ever there is a capacity issue those tunnels will get torn down first so if some UE is sending junk then that UE doing him self no good favours.So UEs sending junk is not going to effect your netork performance that much.Going beyond that if you want you can identifie those IMEIs either on PGW or PCSCF and blacklist them in EIR but I dont think you want to go that far tobe honest.If you really want you can charger the customer for the data since PGW always generate a CDR for any packet transfer.
Hi isuru,
Thanks for your quick response.
With some rough stats, the traffic generated by these bad UEs is a significant one (it is more than the sum of all the valid SIP traffic).
Are there any parameters to be sent in the GTP Create Session Response, which can help to ensure to restrict UEs from initiating such traffic?
Hi mrg,
First Can you show me some stats which you think which is caused by there bad UEs.And from which node are you taking these stats? If you can give me some more information I can give you a recommendation regarding any junk traffic coming from any UE.
For your second questions absolutely when the time network GTP-C session or default bearer establishment we dont know what UE going to do next after the IMS registration if there is sending junk traffic through default bearer then you can either drop them or teardown the IMS bearer completely from PGW or PCSF if you prefer that but I am not advising towards that.If the traffic you are talking about is coming via dedicated bearer during a call then there are mechanisms via RTCP to monitor it notfy or teardown.If you tell me what is exactly you are reffering to I can be more specific.thank you.
Hi Isuru,
Rough stats of the current scenario (kept in terms of ratios).
SIP/ESP - 100 packets
SSDP, BT-DHT, few others - 110 packets
In all the non-SIP protocol cases it is observed that some UEs are retrying a lot, since no response comes from the network.
The traces are taken in the SGW and is observed that they are occurring all the time and not just during the call.
I will suggest you to put the MTU size of the GTP tunnel to around 1500 statically for IPv4 and set path MTU auto discovery(PMTUD).So you can drop larger packets and do not request retransmission of those packets other than sip and for sip you can ask to fragment it and retransmit.
And Also you need to understand once the GRE tunnel is established only places which is going to inspect the traffic is at endpoints so what you can do is you can put a firewall rule in PCSCF internal firewall(Ericsson PCSCF have this) to de-register the subscriber so he or she might not be able to send junk again if he is planing to use that devie.thanks
Are you saying to set this in the GTP Create Session Response?
How to say explicitly for sip to fragment?
Also, in most cases the unexpected protocols are less than 1500 bytes:
As I said after you have established the GRE tunnel only places which are going to inspect the packet application is end points.In the method of MTU size at least you can drop some of them before that and there is a flag in IP layer to check whether you request retransmission via ICMP so you can untick that flag from PGW or Enodeb who were the only other places which might have a chance to investigate the inside of the packet.I have seen PG does have this per apn.otherwise once established only other points ho can check this is UE and PCSCF.But this want impact traffic in any ways because these are non GBR traffic.
If you’re seeing non-SIP related traffic on the ims APN, it’s going to be because you’ve got users trying to send non IMS traffic on the ims APN.
We’ve seen this before with people putting their default APN as ims, then trying to use it for free data.
Check the create session request for these sessions, see if the IMEIs are the same, it may be just one malicious user doing this, in which case you can block them pretty easily.
There’s also a chance your default APN (the one used when no APN is specified) is the ims APN, so users on devices without an APN set are being routed to your ims APN, and less likely but still possible is the carrier bundle you’ve got with an OEM is trying to use ims as the default APN.
Hi Nick, the HSS profile clearly defaults to data APN only, still the packets are initiated over the IMS APN.
What are the other apns you have configured?Do you have HOS apn?
Hi isuru, no HOS APN. Only the data and IMS APNs are present and data APN is the default too.
Which apn is used for MMS and XCAP?
They are not provided. HSS downloads only data and IMS APNs, nothing else.
One final thing I would like to suggest to you if this is a concern for you.You can allocate a different rating group for IMS default bearer and you can start charging customer for the data volume in Default Bearer or you can disconnect the bearer as well .This wont impact for the calls since calls are charged by Ro interface while data is charged via Gy interface.
Thanks isuru, this might be a workable solution too. Thank you!
