top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

Diameter: Receiving 4001 in SLA on Sy interface?

+1 vote
1,244 views

Am trying to integrate between PCRF & OCS of different Vendors using an Sy interface. Policy configuration and integration is fine but for some of the cases am getting a 4001 (Diameter_Authetication_Rejected) in SLA.

As I understand, Authentication is not part of Sy interface. Can anyone let me know the possible scenarios where the 4001 RC can occur on an Sy interface.

posted Jul 6, 2015 by Prashanth P

Looking for an answer?  Promote on:
Facebook Share Button Twitter Share Button LinkedIn Share Button
most likely invalid password :)
commented Jul 6, 2015 by Salil Agrawal
But in SLR no password is present
commented Jul 6, 2015 by Prashanth P
I have checked the base protocol 6733 and this is what it is saying
 DIAMETER_AUTHENTICATION_REJECTED 4001
      The authentication process for the user failed, most likely due to
      an invalid password used by the user.  Further attempts MUST only
      be tried after prompting the user for a new password.
commented Jul 6, 2015 by Salil Agrawal
However it is true that SLR does not have any password parameter so may be some more information needed to comment anything :)
commented Jul 6, 2015 by Salil Agrawal
Right... Sy does not do authentication.  Pls let know what other information you are expecting.
commented Jul 6, 2015 by Prashanth P
This is the information set for SLR -
<SL-Request> ::= <Diameter Header: 8388635, REQ, PXY >
 < Session-Id >
 { Auth-Application-Id }
 { Origin-Host }
 { Origin-Realm }
 { Destination-Realm }
 [ Destination-Host ]
 [ Origin-State-Id ]
 { SL-Request-Type }
 *[ Subscription-Id ]
 *[ Policy-Counter-Identifier ]
 *[ Proxy-Info ]
 *[ Route-Record ]
 *[ AVP ]
commented Jul 6, 2015 by Salil Agrawal
Here are the messages.

Transmission Control Protocol, Src Port: 36480 (36480), Dst Port: 3868 (3868), Seq: 1, Ack: 1, Len: 168
Diameter Protocol
    Version: 0x01
    Length: 168
    Flags: 0xc0
    Command Code: 8388635 Spending-Limit
    ApplicationId: 3GPP Sy (16777302)
    Hop-by-Hop Identifier: 0x05200941
    End-to-End Identifier: 0xa4525761
    [Answer In: 4]
    AVP: Session-Id(263) l=28 f=-M- val=test1;358057;1833;88
    AVP: Auth-Application-Id(258) l=12 f=-M- val=3GPP Sy (16777302)
    AVP: SL-Request-Type(2904) l=16 f=VM- vnd=TGPP val=INITIAL_REQUEST (0)
    AVP: Subscription-Id(443) l=40 f=-M-
    AVP: Origin-Host(264) l=13 f=-M- val=test1
    AVP: Origin-Realm(296) l=15 f=-M- val=test1.com
    AVP: Destination-Realm(283) l=20 f=-M- val=replaced.com
   
   

Transmission Control Protocol, Src Port: 3868 (3868), Dst Port: 36480 (36480), Seq: 1, Ack: 169, Len: 120
Diameter Protocol
    Version: 0x01
    Length: 120
    Flags: 0x40
    Command Code: 8388635 Spending-Limit
    ApplicationId: 3GPP Sy (16777302)
    Hop-by-Hop Identifier: 0x05200941
    End-to-End Identifier: 0xa4525761
    [Request In: 1]
    [Response Time: 0.046002000 seconds]
    AVP: Session-Id(263) l=28 f=-M- val=test1;358057;1833;88
    AVP: Result-Code(268) l=12 f=-M- val=DIAMETER_AUTHENTICATION_REJECTED (4001)
    AVP: Origin-Host(264) l=28 f=-M- val=xyz.replaced.com
    AVP: Origin-Realm(296) l=20 f=-M- val=replaced.com
    AVP: Auth-Application-Id(258) l=12 f=-M- val=3GPP Sy (16777302)
commented Jul 6, 2015 by Prashanth P
Sorry no clue, everything looks ok to me. Please debug the peer to know what is happening :)
commented Jul 6, 2015 by Salil Agrawal
Thank you for trying :-)
 In any case if you come across such issue or a similar... please share the information
commented Jul 6, 2015 by Prashanth P
Will luv to share the info

:)
commented Jul 6, 2015 by Salil Agrawal
Hi Prashanth,

Went through the Spec  http://www.etsi.org/deliver/etsi_ts/129200_129299/129219/12.03.00_60/ts_129219v120300p.pdf may be u can try with the complete set of desired AVPs required for SLR. From Spec what I found SLR message contains below AVPs
<SL-Request> ::= <Diameter Header: 8388635, REQ, PXY >
 < Session-Id >
 { Auth-Application-Id }
 { Origin-Host }
 { Origin-Realm }
 { Destination-Realm }
 [ Destination-Host ]
 [ Origin-State-Id ]
 { SL-Request-Type }
 *[ Subscription-Id ]
 *[ Policy-Counter-Identifier ]
 [ Logical-Access-ID ]
 [ Physical-Access-ID ]
 *[ Proxy-Info ]
 *[ Route-Record ]
 *[ AVP ]

Out of these above AVPs Policy Counter Identifier is a Mandatory AVP for SLR. Also when I checked the spec for Transient Failure and Permanent Failure no scenario I can able to corelate with the 4001.
commented Dec 10, 2015 by Chinmoy Padhi

Similar Questions
+4 votes
Clarification on diameter Sy Interface?

Scenario:
For one subscriber with MSISDN 1234567:

Provisioning in PCRF SPR: Policy_A, Policy_B, Policy_C
OCS active Services: Service_A, Service_B, Service_C

Each PCRF Policy corresponds to OCS Service respectively.

When PCRF requests counters status from OCS in SLR(initial), it does not explicitly specify which counters it needs. PCRF sends MSISDN in [ Subscription-Id ] AVP in SLR(initial). OCS sends all available counters in SLA.

How PCRF will identify which counter(s) is for which policy? How this mapping will be done ?

+2 votes
Sy interface related

I have a question regarding the mapping the Policy counter to Bearers.

Does Policy counter relates to subscriber or it relates to services. I mean how the OCS manages the poilicy counter..
And how it maps to bearers

Lets say we have default bearer which is used for the internet browsing and dedicated bearer for voice.

Now lets say we have Policy counter id1 for subscriber 1, which says the "service as Internet" ..And lets say APN-AMBR (for internet is 5 Mbps upto 5GB ) and 2 Mbps for more than 5GB.

Now in the OCS , we configure for
subscriber1:
Policy counterid1: status 5 Mbps upto 5GB and 2 Mbps for more than 5GB.

And on registration, CCR is sent by PGW to PCRF, which inturn sends the SLR with Policy counter id1 with session Id lets say Sysession1

Now the PCRF sends the CCA to PGW with "service type as Internet", Metering method as "volume" and Rating Group some random value. But there is no way to indicate to PGW about the details of counter like on counting 5Mb, it needs to send the CCR-U to OCS. Or lets say on every 2MB PGW indicates to OCS. The Gy session is created for each bearer ? (i.e one for default bearer here and may be another for dedicated bearer related to that..)

On reaching the 5MB limit, the OCS, sends the SNR to PCRF with the Sysession1.

And when the IP CAN is terminated, CCR-T is sent to OCS and also to PCRF by PGW. PCRF inturn sends the STR to OCS.

Now my Q is about a for 2nd APN for the same subsribers, whatabout the Gy and Sy interfaces, are they reused ?

And whatabout the dedicated bearers related to first APN, will they be using the same Gy and Sy interfaces ?

thanks a lot. Any help or any hints in this very helpful for me to correct my understanding and which will correct my code and finally test it !!!

+5 votes
What is the use of Sy interface?

Can someone provide me some high level detail and good pointer :)

...