Subject: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP

From: "Christopher Richards" <[email-masked]>
Date: Thu, 26 Feb 2004 06:48:51 -0600

Description of issue

A number of wireless specific subscription identifiers are currently
specified (MSISDN, IMSI) but not the IMEISV. In addition, the IMSI is
defined, but the is no way to send the NSAPI identifier used by the
(sub-)session.

Submitter name: Chris Richards
Submitter email address: [email-masked]
Date first submitted: 19 Feb 2004
Reference: 
Document: Diameter Credit Control
Comment type: T
Priority: 1
Section: 8.36
Rationale/Explanation of issue:
The End user IMSI and MSISDN subscription identifiers have been defined.
However, the IMEISV (International Mobile Equipment Idnentity and Software
Version) has been omitted. In addition, the IMSI is defined, but the is no
way to send the NSAPI identifier used by the (sub-)session.

Requested change:

Section 8.46, description of END_USER_IMSI
FROM;

       END_USER_IMSI                                                1  
           The identifier is in international IMSI format, according to  
           the ITU-T E.212 numbering plan as defined in [E121] and  
           [CE121].  
             
TO:

       END_USER_IMSI                                                1  
           The identifier is in international IMSI format, according to  
           the ITU-T E.212 numbering plan as defined in [E121] and  
           [CE121]. In addition, the NSAPI identifier SHOULD be included
           in the final (spare) nibble of the IMSI. The NSAPI is defined
           in 3GPP TS 24.008 [3GPPNSAPI]. 
             
Section 8.46
Addition of:
             
       END_USER_IMEISV                                            5   
           The identifier is in international IMEISV format, according
           to the ITU-T E.212 numbering plan as defined in 3GPP 23.003
           [3GPPIMEI].      

Section 12.16
FROM:

12.16 Subscription-Id-Type AVP  
        
   As defined in Section 8.46, the Subscription-Id-Type AVP (AVP Code 
   450) defines the values 0-4. All remaining values are available for 
   assignment via Designated Expert [IANA].  
    
TO:

12.16 Subscription-Id-Type AVP  
        
   As defined in Section 8.46, the Subscription-Id-Type AVP (AVP Code 
   450) defines the values 0-5. All remaining values are available for 
   assignment via Designated Expert [IANA].  
    
Section 15.1
Addition of:

   [3GPPIMEI]  3rd Generation Partnership Project; Technical 
               Specification Group Core Network, Numbering, addressing 
               and identification, (release 5), 3GPP TS 23.003 
               v. 5.8.0, 2003-012    

   [3GPPNSAPI] 3rd Generation Partnership Project; Technical
               Specification Group Core Network; Mobile radio
               interface Layer 3 specification; Core network
               protocols; Stage 3 (release 5), 3GPP TS 24.008
               v 5.10.0, 2003-12
                
End of change.

Cheers,
Chris.

Shasta Wireless Development
Nortel Networks

Telephone:
+1 972 684 3281
ESN 444 3281

---

From: "Leena Mattila (TU/LMF)" <[email-masked]>
Date: Thu, 26 Feb 2004 14:04:07 +0100

Hi Chris,

as far as I understand IMEI identifies the equipment (e.g. the phone), not the subscriber using it.
Therefore I don't think IMEI should be regarded as one type of subscription. I doubt whether any prepaid subscription is based on the identity of the equipment.

BR,
Leena

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Christopher Richards
Sent: 26. helmikuuta 2004 14:49
To: [email-masked]'
Subject: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP

Description of issue 
A number of wireless specific subscription identifiers are currently specified (MSISDN, IMSI) but not the IMEISV. In addition, the IMSI is defined, but the is no way to send the NSAPI identifier used by the (sub-)session.
The End user IMSI and MSISDN subscription identifiers have been defined. However, the IMEISV (International Mobile Equipment Idnentity and Software Version) has been omitted. In addition, the IMSI is defined, but the is no way to send the NSAPI identifier used by the (sub-)session.
             
TO: 
       END_USER_IMSI                                                1  
             
Section 8.46 
Addition of: 
             
       END_USER_IMEISV                                            5   

TO: 

Section 15.1 
Addition of: 
                
End of change. 
Cheers, 
Chris. 

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

---

From: "Christopher Richards" <[email-masked]>
Date: Thu, 26 Feb 2004 07:20:19 -0600

Hi Leena,

Thanks for your comments.

A subscriber can use a different device to access a network (Just as a
different MSISDN can be used). For example, take their SIM out of the
handheld device and insert it into a PC. Therefore it is an attribute of the
session.

The information is very relevant to a subscribers session usage: it can be
used to determine what kind of services the subscriber is capable of
receiving for that session - over and above the QoS sent for that session.

I.e. is the device capable of receiving streaming video, how big is the
display, what application software (and versions of the software) can it
run, etc, etc.

Let me know if there a better AVP to put this information into?

Best Regards,
Chris.

-----Original Message-----
From: Leena Mattila (TU/LMF) [mailto:[email-masked]] 
Sent: Thursday, February 26, 2004 7:04 AM
To: [email-masked]'
Subject: FW: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP

Hi Chris,

as far as I understand IMEI identifies the equipment (e.g. the phone), not
the subscriber using it. Therefore I don't think IMEI should be regarded as
one type of subscription. I doubt whether any prepaid subscription is based
on the identity of the equipment.

BR,
Leena

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Christopher Richards
Sent: 26. helmikuuta 2004 14:49
To: [email-masked]'
Subject: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP

Description of issue 
(sub-)session. Submitter name: Chris Richards 
way to send the NSAPI identifier used by the (sub-)session. Requested
change: 
             
TO: 
       END_USER_IMSI                                                1  
             
Section 8.46 
Addition of: 
             
       END_USER_IMEISV                                            5   

TO: 

Section 15.1 
Addition of: 
                
End of change. 
Cheers, 
Chris. 

This communication is confidential and intended solely for the addressee(s).
Any unauthorized review, use, disclosure or distribution is prohibited. If
you believe this message has been sent to you in error, please notify the
sender by replying to this transmission and delete the message without
disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption,
interruption, unauthorized amendment, tampering and viruses, and we only
send and receive e-mails on the basis that we are not liable for any such
corruption, interception, amendment, tampering or viruses or any
consequences thereof.

---

From: "Leena Mattila (TU/LMF)" <[email-masked]>
Date: Thu, 26 Feb 2004 14:31:40 +0100

Hi Chris,

I agree, IMEI, NSAPI and lots of other information elements might be interesting to the prepaid system or some other boxes behind it but as you say, they are attributes of the session. They are not different ways to identify the subscription. We should not mix these things.

Since different services will have different interesting attributes to provide to the server we should not try to standardize all of them in DCC, and not even subset of them, because it would be extremely difficult to decide the scope of the subset. IMEI might be important to 3GPP world but maybe not for the rest of the world. Therefore the section 4.1 specifies that each service should specify their rating input (I regard IMEI as one kind of rating input in this case) in their service specific documents. The notation *AVP in the CCR command gives the flexibility to add new service related AVPs in the command without the need of updating the DCC application every time someone wants to transfer a new attribute from the client to the server.

BR,
Leena

-----Original Message-----
From: Christopher Richards [mailto:[email-masked]]
Sent: 26. helmikuuta 2004 15:20
To: Leena Mattila (TU/LMF); [email-masked]'
Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP

Hi Leena, 
Thanks for your comments. 
A subscriber can use a different device to access a network (Just as a different MSISDN can be used). For example, take their SIM out of the handheld device and insert it into a PC. Therefore it is an attribute of the session.
The information is very relevant to a subscribers session usage: it can be used to determine what kind of services the subscriber is capable of receiving for that session - over and above the QoS sent for that session.
I.e. is the device capable of receiving streaming video, how big is the display, what application software (and versions of the software) can it run, etc, etc.
Let me know if there a better AVP to put this information into? 
Best Regards, 
Chris. 

-----Original Message----- 
From: Leena Mattila (TU/LMF) [mailto:[email-masked]] 
Sent: Thursday, February 26, 2004 7:04 AM 
To: [email-masked]' 
Subject: FW: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP 

Hi Chris, 
as far as I understand IMEI identifies the equipment (e.g. the phone), not the subscriber using it. Therefore I don't think IMEI should be regarded as one type of subscription. I doubt whether any prepaid subscription is based on the identity of the equipment.
BR, 
Leena 
-----Original Message----- 
From: [email-masked] [mailto:[email-masked]]On Behalf Of Christopher Richards 
Sent: 26. helmikuuta 2004 14:49 
To: [email-masked]' 
Subject: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP 

Description of issue 
A number of wireless specific subscription identifiers are currently specified (MSISDN, IMSI) but not the IMEISV. In addition, the IMSI is defined, but the is no way to send the NSAPI identifier used by the (sub-)session. Submitter name: Chris Richards 
Submitter email address: [email-masked] 
Date first submitted: 19 Feb 2004 
Reference: 
Document: Diameter Credit Control 
Comment type: T 
Priority: 1 
Section: 8.36 
Rationale/Explanation of issue: 
The End user IMSI and MSISDN subscription identifiers have been defined. However, the IMEISV (International Mobile Equipment Idnentity and Software Version) has been omitted. In addition, the IMSI is defined, but the is no way to send the NSAPI identifier used by the (sub-)session. Requested change: 
Section 8.46, description of END_USER_IMSI 
FROM; 
       END_USER_IMSI                                                1  
           The identifier is in international IMSI format, according to  
           the ITU-T E.212 numbering plan as defined in [E121] and  
           [CE121].  
             
TO: 
       END_USER_IMSI                                                1  
             
Section 8.46 
Addition of: 
             
       END_USER_IMEISV                                            5   

TO: 

Section 15.1 
Addition of: 
                
End of change. 
Cheers, 
Chris.

---

From: <[email-masked]>
Date: Thu, 26 Feb 2004 15:39:41 +0200

Hi Chris,
 
I don't have a strong opinion for or against your proposal,  just seems a bit 3GPP/GPRS specific.
 
If those are really needed in 3GPP, would it be possible that you carry these attributes in a 3GPP 
vendor specific AVPs possibly defined in 3GPP as *AVP?
 
Regards
Marco

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of ext Christopher Richards
Sent: 26 February, 2004 14:49
To: [email-masked]'
Subject: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP

Description of issue 

Requested change: 

       END_USER_IMSI                                                1  
             
TO: 

       END_USER_IMSI                                                1  
             
Section 8.46 
Addition of: 
             
       END_USER_IMEISV                                            5   

Section 12.16 
FROM: 

    
TO: 

    
Section 15.1 
Addition of: 

                
End of change. 

Cheers, 
Chris. 

Telephone: 
+1 972 684 3281 
ESN 444 3281

---

From: "Harri Hakala (TU/LMF)" <[email-masked]>
Date: Thu, 26 Feb 2004 14:19:51 +0100

Hi Christopher,
 
I am not familiar with NSAPI. But according to the TS24.008 the purpose of the 
network service access point identifier information element is to identify the service
access point that is used for the GPRS data transfer at layer 3. 
 
How is NSAPI connected to the user's prepaid subscription?
 
Regards............Harri

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Christopher Richards
Sent: 26. helmikuuta 2004 14:49
To: [email-masked]'
Subject: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP

Description of issue 

Requested change: 

       END_USER_IMSI                                                1  
             
TO: 

       END_USER_IMSI                                                1  
             
Section 8.46 
Addition of: 
             
       END_USER_IMEISV                                            5   

Section 12.16 
FROM: 

    
TO: 

    
Section 15.1 
Addition of: 

                
End of change. 

Cheers, 
Chris. 

Telephone: 
+1 972 684 3281 
ESN 444 3281

---

From: "Christopher Richards" <[email-masked]>
Date: Thu, 26 Feb 2004 08:23:53 -0600

Hi Harri,
 
In 3G, a user can open multiple PDP contexts (sessions). They all are
connected in that they all belong to a single login session (Single AAA
Authenticated session). They all belong to the same IMSI, share the same end
user IP address. However, they are otherwise independent of each other.
There are two ways that this is achieved:
 
(1) Through the use of Secondary PDP contexts: They differ in that they are
intended to be used for different services - as defined by each potentially
having different QoS levels and providing different 5 tuple filters.
(2) Through the use of multiple primary PDP contexts. In which case, they
have no 5 tuple filters. They may (or may not) have different QoS levels.
 
Each of these PDP contexts are identified by this NSAPI value then. Each
using a unique value within the bundle.
 
Operators can assign different subscriptions to the different contexts. Some
subscribers may not even be permitted to use secondary or multiple contexts.
 
As far as I know, the only guaranteed way to tell one from the other or even
to determine what subscription a particular context is, is by using the
NSAPI.

Best Regards, 
Chris. 

-----Original Message-----
From: Harri Hakala (TU/LMF) [mailto:[email-masked]] 
Sent: Thursday, February 26, 2004 7:20 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]; [email-masked]'
Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP

Hi Christopher,
 
I am not familiar with NSAPI. But according to the TS24.008 the purpose of
the 
network service access point identifier information element is to identify
the service
access point that is used for the GPRS data transfer at layer 3. 

Regards............Harri

-----Original Message-----

Description of issue 

Requested change: 

       END_USER_IMSI                                                1  
             
TO: 

       END_USER_IMSI                                                1  
             
Section 8.46 
Addition of: 
             
       END_USER_IMEISV                                            5   

Section 12.16 
FROM: 

    
TO: 

    
Section 15.1 
Addition of: 

                
End of change. 

Cheers, 
Chris. 

Telephone: 
+1 972 684 3281 
ESN 444 3281

---

From: "Christopher Richards" <[email-masked]>
Date: Thu, 26 Feb 2004 08:37:30 -0600

Hi Marco,
 
I agree that this is 3GPP specific: but since DCC already specifies a number
of other 3G/GPRS specific fields natively, it seemed to make sense to
complete the IMSI with the NSAPI and add IMEISV.
 
As you say, for the IMEISV, if it is not added in DCC, it will need to be
added in 3GPP. That's not a problem. I thought I would save the time and do
it in the source document.
 
I think the NSAPI should be included sine the IMSI part is already present. 

Cheers, 
Chris. 

Telephone: 
+1 972 684 3281 
ESN 444 3281 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, February 26, 2004 7:40 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: [email-masked]
Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP

Hi Chris,
 
I don't have a strong opinion for or against your proposal,  just seems a
bit 3GPP/GPRS specific.
 
If those are really needed in 3GPP, would it be possible that you carry
these attributes in a 3GPP 
vendor specific AVPs possibly defined in 3GPP as *AVP?
 
Regards
Marco

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of ext
Christopher Richards
Sent: 26 February, 2004 14:49
To: [email-masked]'
Subject: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP

Description of issue 

Requested change: 

       END_USER_IMSI                                                1  
             
TO: 

       END_USER_IMSI                                                1  
             
Section 8.46 
Addition of: 
             
       END_USER_IMEISV                                            5   

Section 12.16 
FROM: 

    
TO: 

    
Section 15.1 
Addition of: 

                
End of change. 

Cheers, 
Chris. 

Telephone: 
+1 972 684 3281 
ESN 444 3281

---

From: <[email-masked]>
Date: Thu, 26 Feb 2004 17:02:47 +0200

Hi Chris,
 
the reason why we included the IMSI is because a prepaid subsciption may be identified with the IMSI, and yes this is
3GPP specific. However, you may insert your smart card in your PC (e.g. with a PCMCIA card) and still be identified with the
IMSI.
 
The NSAPI is really GPRS specific and dynamically allocated on a per PDP Context basis, it make sense only in GPRS networks
and is actually not adding any value to the IMSI information at the purpose to identify the prepaid subscription. What is the 
actual reason why you want to include the NSAPI, to identify a PDP Context? 
 
Cheers
Marco

-----Original Message-----
From: ext Christopher Richards [mailto:[email-masked]]
Sent: 26 February, 2004 16:38
To: Stura Marco (Nokia-NET/Helsinki)
Cc: [email-masked]
Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP

Hi Marco,
 
I agree that this is 3GPP specific: but since DCC already specifies a number of other 3G/GPRS specific fields natively, it seemed to make sense to complete the IMSI with the NSAPI and add IMEISV.
 
As you say, for the IMEISV, if it is not added in DCC, it will need to be added in 3GPP. That's not a problem. I thought I would save the time and do it in the source document.

Cheers, 
Chris. 

Telephone: 
+1 972 684 3281 
ESN 444 3281 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, February 26, 2004 7:40 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: [email-masked]
Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP

Hi Chris,

 
Regards
Marco

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of ext Christopher Richards
Sent: 26 February, 2004 14:49
To: [email-masked]'
Subject: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP

Description of issue 

Requested change: 

       END_USER_IMSI                                                1  
             
TO: 

       END_USER_IMSI                                                1  
             
Section 8.46 
Addition of: 
             
       END_USER_IMEISV                                            5   

Section 12.16 
FROM: 

    
TO: 

    
Section 15.1 
Addition of: 

                
End of change. 

Cheers, 
Chris. 

Telephone: 
+1 972 684 3281 
ESN 444 3281

---

From: "Harri Hakala (TU/LMF)" <[email-masked]>
Date: Thu, 26 Feb 2004 16:39:40 +0100

Hi Christopher,
 
Thank your for your clarification how to use NSAPI in case of GPRS.
 
Still I think that we should not connect NSAPI to IMSI and use this application specific (GPRS)
combination to identify end user's subscription in prepaid system. As specified in ITU-T E.212 the IMSI 
is composed of a  three digit Mobile Country Code (MCC), a two or three digit Mobile Network
Code (MNC) and a not more than 10 digit Mobile Subscriber Identification Number (MSIN). In other
words, the IMSI is a string of not more than 15 digits. I think that we should stick to the IMSI format
as it is defined in E.212 to identify prepaid subscription.
 
Regards..............Harri

-----Original Message-----
From: Christopher Richards [mailto:[email-masked]]
Sent: 26. helmikuuta 2004 16:24
To: Harri Hakala (TU/LMF); [email-masked]'
Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP

Hi Harri,
 
In 3G, a user can open multiple PDP contexts (sessions). They all are connected in that they all belong to a single login session (Single AAA Authenticated session). They all belong to the same IMSI, share the same end user IP address. However, they are otherwise independent of each other. There are two ways that this is achieved:
 
(1) Through the use of Secondary PDP contexts: They differ in that they are intended to be used for different services - as defined by each potentially having different QoS levels and providing different 5 tuple filters.
(2) Through the use of multiple primary PDP contexts. In which case, they have no 5 tuple filters. They may (or may not) have different QoS levels.
 
Each of these PDP contexts are identified by this NSAPI value then. Each using a unique value within the bundle.
 
Operators can assign different subscriptions to the different contexts. Some subscribers may not even be permitted to use secondary or multiple contexts.
 
As far as I know, the only guaranteed way to tell one from the other or even to determine what subscription a particular context is, is by using the NSAPI.

Best Regards, 
Chris. 

-----Original Message-----
From: Harri Hakala (TU/LMF) [mailto:[email-masked]] 
Sent: Thursday, February 26, 2004 7:20 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]; [email-masked]'
Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP

Hi Christopher,

 
Regards............Harri

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Christopher Richards
Sent: 26. helmikuuta 2004 14:49
To: [email-masked]'
Subject: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP

Description of issue 

Requested change: 

       END_USER_IMSI                                                1  
             
TO: 

       END_USER_IMSI                                                1  
             
Section 8.46 
Addition of: 
             
       END_USER_IMEISV                                            5   

Section 12.16 
FROM: 

    
TO: 

    
Section 15.1 
Addition of: 

                
End of change. 

Cheers, 
Chris. 

Telephone: 
+1 972 684 3281 
ESN 444 3281

---

From: <[email-masked]>
Date: Thu, 26 Feb 2004 17:43:19 +0200

>As far as I know, the only guaranteed way to tell one from the other or even to determine what subscription a particular context is, is by using the NSAPI.
 
Chris, the NSAPI is dynamically selected by the terminal when the PDP Conetxt is activated. I doubt you can link a subscription to some parameter
that is dynamically selected by the terminal i.e. that you don't know beforehand. Actually the NSAPI it self it dosn't even tell that this is a secondary
PDP Context, what tell it is the linked NSAPI.
 
I have still concerns on the usability of the NSAPI to identify a specific prepaid subscription. 
 
Cheers
Marco

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of ext Christopher Richards
Sent: 26 February, 2004 16:24
To: 'Harri Hakala (TU/LMF)'; [email-masked]'
Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP

Hi Harri,

 

Best Regards, 
Chris. 

-----Original Message-----
From: Harri Hakala (TU/LMF) [mailto:[email-masked]] 
Sent: Thursday, February 26, 2004 7:20 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]; [email-masked]'
Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP

Hi Christopher,

 
Regards............Harri

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Christopher Richards
Sent: 26. helmikuuta 2004 14:49
To: [email-masked]'
Subject: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP

Description of issue 

Requested change: 

       END_USER_IMSI                                                1  
             
TO: 

       END_USER_IMSI                                                1  
             
Section 8.46 
Addition of: 
             
       END_USER_IMEISV                                            5   

Section 12.16 
FROM: 

    
TO: 

    
Section 15.1 
Addition of: 

                
End of change. 

Cheers, 
Chris. 

Telephone: 
+1 972 684 3281 
ESN 444 3281

---

From: "Christopher Richards" <[email-masked]>
Date: Thu, 26 Feb 2004 10:34:55 -0600

Hi All,
 
I don't mind removing the NSAPI proposed addition and leave it to 3GPP to
determine it's usefulness.
 
Are there any comments regarding the IMEISV addition?

Best Regards, 
Chris. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, February 26, 2004 9:43 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]; [email-masked];
[email-masked]

>As far as I know, the only guaranteed way to tell one from the other or
even to determine what subscription a particular context is, is by using the
NSAPI.
 
Chris, the NSAPI is dynamically selected by the terminal when the PDP
Conetxt is activated. I doubt you can link a subscription to some parameter
that is dynamically selected by the terminal i.e. that you don't know
beforehand. Actually the NSAPI it self it dosn't even tell that this is a
secondary
PDP Context, what tell it is the linked NSAPI.
 
I have still concerns on the usability of the NSAPI to identify a specific
prepaid subscription. 
 
Cheers
Marco

-----Original Message-----

Hi Harri,

 

Best Regards, 
Chris. 

-----Original Message-----
From: Harri Hakala (TU/LMF) [mailto:[email-masked]] 
Sent: Thursday, February 26, 2004 7:20 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]; [email-masked]'
Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP

Hi Christopher,

 
Regards............Harri

-----Original Message-----

Description of issue 

Requested change: 

       END_USER_IMSI                                                1  
             
TO: 

       END_USER_IMSI                                                1  
             
Section 8.46 
Addition of: 
             
       END_USER_IMEISV                                            5   

Section 12.16 
FROM: 

    
TO: 

    
Section 15.1 
Addition of: 

                
End of change. 

Cheers, 
Chris. 

Telephone: 
+1 972 684 3281 
ESN 444 3281

---

From: <[email-masked]>
Date: Thu, 26 Feb 2004 19:36:23 +0200

>Are there any comments regarding the IMEISV addition?
 
One concern is that the IMEISV identify the equipment, then the Subscription-Id AVP is perhaps not the appropriate
container for it.  I think that a user identity (e.g. MSISDN, IMSI, SIP URI) MUST always be present in the request to
really identify the user.
 
I would prefere a separate AVP to carry the IMEISV e.g. Equipement-Identification AVP, but I'm not sure whether we
should define it in the DCC or in 3GPP service specific documents.
 
Does somebody have opinions? Is there any other types of equipement identities that could benefit from this AVP?
 
Cheers
Marco

-----Original Message-----
From: ext Christopher Richards [mailto:[email-masked]]
Sent: 26 February, 2004 18:35
To: Stura Marco (Nokia-NET/Helsinki); [email-masked]; [email-masked]
Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP

Hi All,
 
I don't mind removing the NSAPI proposed addition and leave it to 3GPP to determine it's usefulness.

Best Regards, 
Chris. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, February 26, 2004 9:43 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]; [email-masked]; [email-masked]
Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP

 
 
Cheers
Marco

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of ext Christopher Richards
Sent: 26 February, 2004 16:24
To: 'Harri Hakala (TU/LMF)'; [email-masked]'
Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP

Hi Harri,

 

Best Regards, 
Chris. 

-----Original Message-----
From: Harri Hakala (TU/LMF) [mailto:[email-masked]] 
Sent: Thursday, February 26, 2004 7:20 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]; [email-masked]'
Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP

Hi Christopher,

 
Regards............Harri

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Christopher Richards
Sent: 26. helmikuuta 2004 14:49
To: [email-masked]'
Subject: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP

Description of issue 

Requested change: 

       END_USER_IMSI                                                1  
             
TO: 

       END_USER_IMSI                                                1  
             
Section 8.46 
Addition of: 
             
       END_USER_IMEISV                                            5   

Section 12.16 
FROM: 

    
TO: 

    
Section 15.1 
Addition of: 

                
End of change. 

Cheers, 
Chris. 

Telephone: 
+1 972 684 3281 
ESN 444 3281

---

From: "Harri Hakala (TU/LMF)" <[email-masked]>
Date: Thu, 26 Feb 2004 18:56:10 +0100

Hi Christopher,

I think that we should not add IMEISV either. First I don't think that prepaid subscription should be based on the identity of the equipment. IMEI of the terminal does not specify who is using the terminal and if the terminal is stolen that may cause lot of harm to the owner of the  terminal, if IMEI is used to identify the prepaid subscription. Secondly if we add terminal identity of one system (3GPP), then we should add terminal identities of other systems as well.

regards...........Harri

-----Original Message-----
From: Christopher Richards
To: [email-masked]'; Harri Hakala (TU/LMF); [email-masked]
Sent: 26.2.2004 17:34
Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP

Hi All,
 
I don't mind removing the NSAPI proposed addition and leave it to 3GPP
to determine it's usefulness.

Best Regards, 
Chris. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, February 26, 2004 9:43 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]; [email-masked];
[email-masked]
Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type
AVP

>As far as I know, the only guaranteed way to tell one from the other or
even to determine what subscription a particular context is, is by using
the NSAPI.
 
Chris, the NSAPI is dynamically selected by the terminal when the PDP
Conetxt is activated. I doubt you can link a subscription to some
parameter
that is dynamically selected by the terminal i.e. that you don't know
beforehand. Actually the NSAPI it self it dosn't even tell that this is
a secondary
PDP Context, what tell it is the linked NSAPI.
 
I have still concerns on the usability of the NSAPI to identify a
specific prepaid subscription. 
 
Cheers
Marco

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
ext Christopher Richards
Sent: 26 February, 2004 16:24
To: 'Harri Hakala (TU/LMF)'; [email-masked]'
Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type
AVP

Hi Harri,
 
In 3G, a user can open multiple PDP contexts (sessions). They all are
connected in that they all belong to a single login session (Single AAA
Authenticated session). They all belong to the same IMSI, share the same
end user IP address. However, they are otherwise independent of each
other. There are two ways that this is achieved:
 
(1) Through the use of Secondary PDP contexts: They differ in that they
are intended to be used for different services - as defined by each
potentially having different QoS levels and providing different 5 tuple
filters.
(2) Through the use of multiple primary PDP contexts. In which case,
they have no 5 tuple filters. They may (or may not) have different QoS
levels.

Operators can assign different subscriptions to the different contexts.
Some subscribers may not even be permitted to use secondary or multiple
contexts.
 
As far as I know, the only guaranteed way to tell one from the other or
even to determine what subscription a particular context is, is by using
the NSAPI.

Best Regards, 
Chris. 

-----Original Message-----
From: Harri Hakala (TU/LMF) [mailto:[email-masked]] 
Sent: Thursday, February 26, 2004 7:20 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]; [email-masked]'
Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type
AVP

Hi Christopher,
 
I am not familiar with NSAPI. But according to the TS24.008 the purpose
of the 
network service access point identifier information element is to
identify the service
access point that is used for the GPRS data transfer at layer 3. 

Regards............Harri

-----Original Message-----

Description of issue 

Submitter name: Chris Richards 
Submitter email address: [email-masked] 
Date first submitted: 19 Feb 2004 
Reference: 
Document: Diameter Credit Control 
Comment type: T 
Priority: 1 
Section: 8.36 
Rationale/Explanation of issue: 
The End user IMSI and MSISDN subscription identifiers have been defined.
However, the IMEISV (International Mobile Equipment Idnentity and
Software Version) has been omitted. In addition, the IMSI is defined,
but the is no way to send the NSAPI identifier used by the
(sub-)session.

Requested change: 

       END_USER_IMSI                                                1  

TO: 

       END_USER_IMSI                                                1  

             
Section 8.46 
Addition of: 
             
       END_USER_IMEISV                                            5   

Section 12.16 
FROM: 

    
TO: 

    
Section 15.1 
Addition of: 

                
End of change. 

Cheers, 
Chris. 

Telephone: 
+1 972 684 3281 
ESN 444 3281 

This communication is confidential and intended solely for the
addressee(s). Any unauthorized review, use, disclosure or distribution
is prohibited. If you believe this message has been sent to you in
error, please notify the sender by replying to this transmission and
delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption,
interruption, unauthorized amendment, tampering and viruses, and we only
send and receive e-mails on the basis that we are not liable for any
such corruption, interception, amendment, tampering or viruses or any
consequences thereof.

---

From: "Christopher Richards" <[email-masked]>
Date: Thu, 26 Feb 2004 19:08:52 -0600

Harri,

I am not suggesting that the prepaid subscription should be based upon
IMEISV - I'm is suggesting that the IMEISV should be sent in place of the
IMSI or other subscriber attributes - there is no possible way that a stolen
terminal user can pretend to be a valid user without the IMSI anyway: a
stolen terminal will not be able to use network resources without the
SIM/IMSI anyway (Apart for emergency voice calls which do not require a
SIM/IMSI). 

I am suggesting that there are valid reasons that the credit control server
has for knowing this information - especially in the 3GPP NAS world
(Possibly in 3GPP2. Maybe less so in the SIP world). I am recommending that
in addition to the IMSI, MSISDN, IP address, the IMEISV MAY also be
included.

Best Regards,
Chris.

-----Original Message-----
From: Harri Hakala (TU/LMF) [mailto:[email-masked]] 
Sent: Thursday, February 26, 2004 11:56 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]; [email-masked]' ';
[email-masked] '

Hi Christopher,

I think that we should not add IMEISV either. First I don't think that
prepaid subscription should be based on the identity of the equipment. IMEI
of the terminal does not specify who is using the terminal and if the
terminal is stolen that may cause lot of harm to the owner of the  terminal,
if IMEI is used to identify the prepaid subscription. Secondly if we add
terminal identity of one system (3GPP), then we should add terminal
identities of other systems as well.

regards...........Harri

-----Original Message-----
From: Christopher Richards
To: [email-masked]'; Harri Hakala (TU/LMF); [email-masked]
Sent: 26.2.2004 17:34
Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP

Hi All,

Best Regards, 
Chris. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, February 26, 2004 9:43 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]; [email-masked];
[email-masked]

secondary PDP Context, what tell it is the linked NSAPI.

Cheers
Marco

-----Original Message-----

Hi Harri,

 

Best Regards, 
Chris. 

-----Original Message-----
From: Harri Hakala (TU/LMF) [mailto:[email-masked]] 
Sent: Thursday, February 26, 2004 7:20 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]; [email-masked]'
Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP

Hi Christopher,
 
I am not familiar with NSAPI. But according to the TS24.008 the purpose of
the 
network service access point identifier information element is to identify
the service access point that is used for the GPRS data transfer at layer 3.

Regards............Harri

-----Original Message-----

Description of issue 

Requested change: 

       END_USER_IMSI                                                1  

TO: 

       END_USER_IMSI                                                1  

             
Section 8.46 
Addition of: 
             
       END_USER_IMEISV                                            5   

Section 12.16 
FROM: 

    
TO: 

    
Section 15.1 
Addition of: 

                
End of change. 

Cheers, 
Chris. 

Telephone: 
+1 972 684 3281
ESN 444 3281

---

From: <[email-masked]>
Date: Fri, 27 Feb 2004 03:10:14 +0200

assigned issue 22.

John
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of ext Christopher Richards
Sent: 26 February, 2004 14:49
To: [email-masked]'
Subject: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP

Description of issue 
             
TO: 
       END_USER_IMSI                                                1  
             
Section 8.46 
Addition of: 
             
       END_USER_IMEISV                                            5   

TO: 

Section 15.1 
Addition of: 
                
End of change. 
Cheers, 
Chris.

---

From: "Harri Hakala (TU/LMF)" <[email-masked]>
Date: Fri, 27 Feb 2004 08:06:04 +0100

Hi Christopher,

Since the Subscription-Id in DCC is used to specify user's prepaid subscription,
we should not add IMEISV to Subscription-Id-Type AVP.

I agree with you that there may be valid reasons to carry IMEISV to the CC server,
for instance to monitor misused prepaid subscriptions, in case when user has prepaid
SIM without that person identity is known. 

If we want to add IMEISV then I agree with Marco&Leena that we need a separate AVP to
carry the Equipment-Id. This APV should be generic enough to carry other Equipment-Ids
than IMEISV as well. It may be better then that the APV is type of UTF8String, so that
we do not list all different equipment Ids. Or alternatively this AVP should be defined
in service (e.g. 3GPP) specific documents.

Regards........Harri

-----Original Message-----
From: Christopher Richards [mailto:[email-masked]]
Sent: 27. helmikuuta 2004 3:09
To: Harri Hakala (TU/LMF); [email-masked]' '; [email-masked] '
Subject: RE: [AAA-WG]: DCC: Inclusion of IMEI in Subscription-Id-Type AVP

Harri, 
I am not suggesting that the prepaid subscription should be based upon IMEISV - I'm is suggesting that the IMEISV should be sent in place of the IMSI or other subscriber attributes - there is no possible way that a stolen terminal user can pretend to be a valid user without the IMSI anyway: a stolen terminal will not be able to use network resources without the SIM/IMSI anyway (Apart for emergency voice calls which do not require a SIM/IMSI). 
I am suggesting that there are valid reasons that the credit control server has for knowing this information - especially in the 3GPP NAS world (Possibly in 3GPP2. Maybe less so in the SIP world). I am recommending that in addition to the IMSI, MSISDN, IP address, the IMEISV MAY also be included.
Best Regards, 
Chris.

---

From: <[email-masked]>
Date: Fri, 27 Feb 2004 09:13:48 +0200

Hi Chris,
 
>I am suggesting that there are valid reasons that the credit control server has for knowing this information - especially in the 3GPP NAS world (Possibly in 3GPP2. Maybe less so in the 
>SIP world). I am recommending that in addition to the IMSI, MSISDN, IP address, the IMEISV MAY also be included.
 
My question would be, what other equipment identities could be included other than 3GPP IMEISV. 
What is the 3GPP 2 equipment identity? Is ther a way to identify other type of equipments 
(e.g. MAC address or..)?
 
Certainly the Subscription-Id AVP is not the most appropriate container for the IMEI.
I've no problem my self to define a new AVP Equipment-Identification or something similar
if we can find other applications than 3GPP. But, if only 3GPP is using the AVP the best
way would be that 3GPP defines this AVP.
 
You may know that 3GPP can use 3GPP vendor-id and value assigned in 3GPP i.e. the AVP
can be fully handled by 3GPP without IETF/IANA interactions.
 
Regards
Marco