Subject: [AAA-WG]: DCC Issue 22: (Updated) Inclusion of IMEISV in CCR

From: "Christopher Richards" <[email-masked]>
Date: Sat, 6 Mar 2004 16:26:38 -0600

Hi,

After some discussions, I have updated the original proposal for sending the
IMEI from the DCC client to the server. Since the IMEISV format is already
well defined and described, I did not see the need to convert it to another
format. Additionally, the included definition allows for the inclusion of
the device software version along with the IMEI. I included the general
EUI64 type format for use by unspecified equipment types.

Submitter name: Chris Richards
Submitter email address: [email-masked]
Date first submitted: 19 Feb 2004
Reference: issue 22
Document: Diameter Credit Control
Comment type: T
Priority: 1
Section: 
Rationale/Explanation of issue:

CHANGED SECTION 3.1 Credit-Control-Request (CCR) Command 
FROM:
...
                                    *[ Service-Parameter-Info ]  
                                    *[ CC-Correlation-Id ] 
                                    *[ Proxy-Info ] 
                                    *[ Route-Record ] 
                                    *[ AVP ] 

TO:
...
                                    *[ Service-Parameter-Info ]  
                                    *[ CC-Correlation-Id ] 
                                    *[ Proxy-Info ] 
                                    *[ Route-Record ] 
                                     [ User-Equipment-Info ]
                                    *[ AVP ] 

CHANGED SECTION 5.2 First Interrogation  3rd para
FROM
...
   The Event-Timestamp AVP contains the time when the service event is 
   requested in the service element. The Subscription-Id AVP SHOULD be 
   included to identify the End-User in the credit-control server.  
...        
        
TO:
...
   The Event-Timestamp AVP contains the time when the service event is 
   requested in the service element. The Subscription-Id AVP SHOULD be 
   included to identify the End-User in the credit-control server. The
   credit control client MAY include the User-Equipment-Info AVP so
   that the credit control server has some indication about the type
   and capabilities of the end user access device. How the credit
   control server uses this information is outside the scope of this
   document.
...

CHANGED SECTION 8. Credit Control AVPs  
FROM
...
   Unit-Value        445  8.8    Grouped    | M  |  P  |    |  V  | Y  | 
   Used-Service-Unit 446  8.19   Grouped    | M  |  P  |    |  V  | Y  |  
   Value-Digits      447  8.10   Integer64  | M  |  P  |    |  V  | Y  | 
   Validity-Time     448  8.33   Unsigned32 | M  |  P  |    |  V  | Y  | 
   
TO:
...
   Unit-Value        445  8.8    Grouped    | M  |  P  |    |  V  | Y  | 
   Used-Service-Unit 446  8.19   Grouped    | M  |  P  |    |  V  | Y  |  
   User-Equipment    TBD  8.48   Grouped    |    |  P  |    |  V  | Y  |
     -Info                                  |    |     |    |     |    |
   User-Equipment    TBD  8.49   Unsigned32 |    |  P  |    |  V  | Y  |
     -Type                                  |    |     |    |     |    |
   User-Equipment    TBD  8.50   UTF8String |    |  P  |    |  V  | Y  |
     -Value                                 |    |     |    |     |    |
   Value-Digits      447  8.10   Integer64  | M  |  P  |    |  V  | Y  | 
   Validity-Time     448  8.33   Unsigned32 | M  |  P  |    |  V  | Y  | 

NEW SECTIONS 8.48 to 8.50:
8.48 User-Equipment-Info AVP 

   The User-Equipment-Info AVP (AVP Code TBD) is of type Grouped, and 
   allows the Credit-control client to indicate the identity and capability
   of the terminal the subscriber is using for the connection to network. 
   
   It has the following ABNF grammar:  
        
                 User-Equipment-Info ::= < AVP Header: TBD >  
                                         { User-Equipment-Info-Type }  
                                         { User-Equipment-Info-Value }  

8.49 User-Equipment-Info-Type AVP 

   The User-Equipment-Info-Type AVP is of type Unsigned32 (AVP Code TBD) 
   and defines the type of the user equipment information contained in
   the User-Equipment-Info-Value AVP.
   
   The identifier can be one of the following:  
        
      IMEISV                                            0  
    
           The identifier contains the International Mobile Equipment
           Identifier and Software Version in the international IMEISV
           format according to 3GPP TS 23.003 [3GPPIMEI].  
                
      MAC                                               1  
           The 48-bit MAC address is formatted as described in
           [RAD802.1X].
           
      EUI64                                             2
      
           There are a number of types of terminals that have identifiers
           other than 3GPP IMEI or IEEE 802 MACs. These identifiers can
           be converted to modified EUI-64 format as described in
           [IPv6Addr].
    
8.50 User-Equipment-Info-Value AVP

   The User-Equipment-Info-Value AVP (AVP Code TBD) is of type UTF8String. 
   The User-Equipment-Info-Type AVP defines which type of identifier is
   used.  

CHANGED SECTION 10.1 Credit Control AVP Table  
FROM:
...
         Used-Service-Unit             | 0+  | 0   | 
         User-Name                     | 0-1 | 0-1 | 
         Validity-Time                 | 0   | 0-1 | 
         ------------------------------|-----+-----+  

TO:
...
         Used-Service-Unit             | 0+  | 0   | 
         User-Equipment-Info           | 0-1 | 0   |
         User-Name                     | 0-1 | 0-1 | 
         Validity-Time                 | 0   | 0-1 | 
         ------------------------------|-----+-----+  

NEW SECTION:

12.18 User-Equipment-Info-Type AVP  
        
   As defined in Section 8.49, the User-Equipment-Info-Type AVP (AVP
   Code TBD) defines the values 0-2. All remaining values are
   available for assignment via Designated Expert [IANA].  

CHANGED SECTION 15.1 Normative  
FROM:
...

ADD:
...
   [RAD802.1X]   P. Congdon, et.al "IEEE 802.1X RADIUS Usage Guidelines", 
                 RFC 3580, September 2003. 
     
   [EUI64]      IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) 
                Registration Authority", 
                http://standards.ieee.org/regauth/oui/tutorials/EUI64.html, 
                March 1997. 

   [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-12

---

From: <[email-masked]>
Date: Mon, 8 Mar 2004 07:26:22 +0200

Issue updated.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of ext Christopher Richards
Sent: 07 March, 2004 00:27
To: [email-masked]
Cc: Harri Hakala (TU/LMF); Stura Marco (Nokia-NET/Helsinki); 'Leena Mattila (TU/LMF)'
Subject: [AAA-WG]: DCC Issue 22: (Updated) Inclusion of IMEISV in CCR

Hi, 

After some discussions, I have updated the original proposal for sending the IMEI from the DCC client to the server. Since the IMEISV format is already well defined and described, I did not see the need to convert it to another format. Additionally, the included definition allows for the inclusion of the device software version along with the IMEI. I included the general EUI64 type format for use by unspecified equipment types.

TO: 
... 

TO: 
... 

TO: 
... 

   

   
        
      IMEISV                                            0  

      MAC                                               1  
           
      EUI64                                             2 

TO: 
... 

NEW SECTION: 

ADD: 
...

---

From: "Leena Mattila (TU/LMF)" <[email-masked]>
Date: Mon, 8 Mar 2004 14:06:02 +0100

Hi Chris,

sounds ok. Not being an expert on identifiers but isn't the basic EUI-64 format now missing from the list of possible formats, I only saw a reference to a Modified EUI-64 [IPv6Addr]?

BR,
Leena

-----Original Message-----
From: Christopher Richards [mailto:[email-masked]]
Sent: 7. maaliskuuta 2004 0:27
To: [email-masked]
Cc: Harri Hakala (TU/LMF); Marco Stura (E-mail); Leena Mattila (TU/LMF)
Subject: [AAA-WG]: DCC Issue 22: (Updated) Inclusion of IMEISV in CCR

Hi, 

TO: 
... 

TO: 
... 

        

        
      IMEISV                                            0  

      MAC                                               1  
           
      EUI64                                             2 

        

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: "Harri Hakala (TU/LMF)" <[email-masked]>
Date: Wed, 10 Mar 2004 08:41:20 +0100

Hi,

> sounds ok. Not being an expert on identifiers but isn't the 
> basic EUI-64 format now missing from the list of possible 
> formats, I only saw a reference to a Modified EUI-64 [IPv6Addr]?
To be able to close also this issue, I take the liberty to update
the issue to cover also pure EUI-64 format. It may be good also to
mention that there may be other approaches for creating Modified EUI-64
format than those described in [IPv6Addr]. These methods may be
needed if length of the company_id and vendor_supplied_id fields are other
than those mentioned in MAC-48 or EUI-64.

Below is updated proposal.

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

CHANGED SECTION 5.2 First Interrogation  3rd paragraph 
FROM 
... 
   The Event-Timestamp AVP contains the time when the service event is 
   requested in the service element. The Subscription-Id AVP SHOULD be 
   included to identify the End-User in the credit-control server.  
...        
        
TO: 
... 

TO: 
... 
   Unit-Value        445  8.8    Grouped    | M  |  P  |    |  V  | Y  | 
   Used-Service-Unit 446  8.19   Grouped    | M  |  P  |    |  V  | Y  |  
   User-Equipment    TBD  8.48   Grouped    |    | P,M |    |  V  | Y  | 
     -Info                                  |    |     |    |     |    | 
   User-Equipment    TBD  8.49   Unsigned32 |    | P,M |    |  V  | Y  | 
     -Type                                  |    |     |    |     |    | 
   User-Equipment    TBD  8.50   UTF8String |    | P,M |    |  V  | Y  | 
     -Value                                 |    |     |    |     |    | 
   Value-Digits      447  8.10   Integer64  | M  |  P  |    |  V  | Y  | 
   Validity-Time     448  8.33   Unsigned32 | M  |  P  |    |  V  | Y  | 

        

        
      IMEISV                                            0  

      MAC                                               1  
           
      EUI64                                              2 
           The 64-bit identifier used to identify hardware instance of
           the product as defined in [EUI64].           

      MODIFIED_EUI64                                     3 
      
           There are a number of types of terminals that have identifiers 
           other than IMEI, IEEE 802 MACs or EUI-64. These identifiers can 
           be converted to modified EUI-64 format as described in 
           [IPv6Addr] or using some other methods referred to in the
           service specific documentation.    

   As defined in Section 8.49, the User-Equipment-Info-Type AVP (AVP 
   Code TBD) defines the values 0-3. All remaining values are 
   available for assignment via Designated Expert [IANA].  

> From: Leena Mattila (TU/LMF) 
> Sent: 8. maaliskuuta 2004 15:06
> To: 'Christopher Richards'
> Cc: Harri Hakala (TU/LMF); Marco Stura (E-mail); [email-masked]
> Subject: RE: [AAA-WG]: DCC Issue 22: (Updated) Inclusion of IMEISV in
> CCR
> 
> 
> Hi Chris,
> 
> sounds ok. Not being an expert on identifiers but isn't the 
> basic EUI-64 format now missing from the list of possible 
> formats, I only saw a reference to a Modified EUI-64 [IPv6Addr]?
> 
> BR,
> Leena
> 
> After some discussions, I have updated the original proposal 
> for sending the IMEI from the DCC client to the server. Since 
> the IMEISV format is already well defined and described, I 
> did not see the need to convert it to another format. 
> Additionally, the included definition allows for the 
> inclusion of the device software version along with the IMEI. 
> I included the general EUI64 type format for use by 
> unspecified equipment types.
>      -Info                                  |    |     |    | 
>     |    | 
>      -Type                                  |    |     |    | 
>     |    | 
>      -Value                                 |    |     |    | 
>     |    |

---

From: "Christopher Richards" <[email-masked]>
Date: Wed, 10 Mar 2004 08:56:20 -0600

Hi Harri,

The change seems fine to me.

Best Regards,
Chris.

-----Original Message-----
From: Harri Hakala (TU/LMF) [mailto:[email-masked]] 
Sent: Wednesday, March 10, 2004 1:41 AM
To: Leena Mattila (TU/LMF); Richards, Christopher [RICH2:2Q40:EXCH]
Cc: 'Marco Stura (E-mail)'; [email-masked]'
Subject: RE: [AAA-WG]: DCC Issue 22: (Updated) Inclusion of IMEISV in CCR

Hi,

> formats, I only saw a reference to a Modified EUI-64 [IPv6Addr]?
To be able to close also this issue, I take the liberty to update the issue
to cover also pure EUI-64 format. It may be good also to mention that there
may be other approaches for creating Modified EUI-64 format than those
described in [IPv6Addr]. These methods may be needed if length of the
company_id and vendor_supplied_id fields are other than those mentioned in
MAC-48 or EUI-64.

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

        
TO: 
... 

TO: 
... 

        

        
      IMEISV                                            0  

      MAC                                               1  
           
      EUI64                                              2 

      MODIFIED_EUI64                                     3 

        

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.