1 / 6

Design assumptions

Design assumptions. 1. Introduction

cutter
Download Presentation

Design assumptions

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Design assumptions • 1. Introduction • We presented three stage 2 proposals for realizing one-way roaming from ANSI-41 to GSM without Service Orders in IIF at the previous TR45.2 meeting. We study further about design assumptions, security mechanism and the stage 2 proposals. And we suggest another stage 2 proposal for approval. • 2. Design assumptions • General: • A-key is placed both in SIM and ANSI-41 HLR/AC. • SSD basically is kept both in SIM and ANSI-41 HLR/AC, maybe kept in IIF. • SSD is not updated during the GSM roaming. • GSM network: • There is no impact on GSM infrastructure. • ANSI-41 HLR/AC: • Security function (i.e.,CAVE) at ANSI-41 HLR/AC is not changed. • Some enhancements may be necessary for interworking with IIF. • IIF: • No SO (Service Order) is required in IIF. • Temporary data base is necessary for GSM roaming subscriber while he/she is roaming in GSM. • Security mechanism may be needed for security interworking. • IIF may be owned by either ANSI-41 operator, GSM operator or third party. Therefore, it is not desirable that a peculiar security algorithm is located there. In other words, compromise of security function (if any) will not jeopardize the existing ANSI-41 / GSM security scheme. • SIM: • Dual profile (ANSI-41 profile and GSM profile) is stored within SIM. • There is one to one correspondence between IMSI in GSM profile and MSID in ANSI profile. • GSM specific command is invoked from GSM ME, while the MS is roaming in GSM. Therefore, RUN GSM ALGORITHM is invoked for GSM authentication. • GSM authentication algorithms (A3 and A8) can be selected by Home (ANSI-41) operator.

  2. Security mechanism 3. Security mechanism The security mechanism is as follows. The mechanism is under discussing. But we think it is enough that RANDU, AUTHU and SSD come from HLR/AC. Therefore, we don’t care whether stage 2 proposals. We only care about the speed for standardizing. UIM ME GSM MSC/VLR IIF ANSI-41 HLR/AC RAND (128bits) Security Mechanism (FFS) RANDU (24bits) SRES (32bits) AUTHU (18bits) Kc (64bits) SSD (128bits) RAND (128bits) RUN GSM ALGORITHM (RAND) RUN GSM ALGORITHM ack (SRES, Kc) SRES (32bits)

  3. New stage 2 proposal 4. Proposal 4 (refer to p.4, 5) ESN QUERY message is newly defined. IIF can query the ESN value to the HLR by the new message. The processing of ANSI-41 HLR/AC is based on “AC initiated Unique Challenge”. This message is used only for avoiding MSID/ESN mismatch state in this case. This message may be used for another functions. *GLR(Gateway Location Register) : Subscription Data is temporary registered. This is all for us to desire to do in the project that is “Enhancements to support SIM Roaming from ANSI-41-D CDMA to GSM”.

  4. Proposal 4 (Registration with Authentication) MS GSM MSC/VLR IIF ANSI-41 HLR/AC ANSI-41 MSC/VLR Location_Area_Update (IMSI) New message for IIF. SEND_AUTHENTICATION_INFO [IMSI] ESNQUERY [MSID] esnquery [ESN] AUTHREQ [MSID, ESN] authreq [RANDU, AUTHU, SSD] SEND_AUTHENTICATION_INFO ack [ AuthenticationSetList (RAND, SRES, Kc)] This mapping depends on the security mechanism. Authenticate (RAND) Authenticate ack (SRES) ASRRT UPDATE_LOCATION [IMSI] ASREPORT asreport REGNOT [MSID, ESN] REGCANC [MSID, ESN] regcanc regnot [profile] INSERT_SUBSCRIBER_DATA INSERT_SUBSCRIBER_DATA ack UPDATE_LOCATION ack Location_Area_Update ack

  5. Proposal 4 (Registration without Authentication) MS GSM MSC/VLR IIF ANSI-41 HLR/AC ANSI-41 MSC/VLR Location_Area_Update (IMSI) Authenticate (RAND) Authenticate ack (SRES) New message for IIF. UPDATE_LOCATION [IMSI] ESNQUERY [MSID] esnquery [ESN] REGNOT [MSID, ESN] REGCANC [MSID, ESN] regcanc regnot [profile] INSERT_SUBSCRIBER_DATA INSERT_SUBSCRIBER_DATA ack UPDATE_LOCATION ack Location_Area_Update ack New message for IIF. ACT_SS ESNQUERY [MSID] esnquery [ESN] FEATREQ [MSID, ESN]

  6. Conclusion 5. Conclusion We suggest a proposal 4 because of the speed of standardizing. This proposal defines a new message. But the message is very simple and does not impact on another ANSI-41 messages. The figure below is our proposed schedule submitted to G-95 meeting. RF95-N Doc. 05/00 P2 Stage 1 Work P1: One-way roaming (without SO) P2: Two-way roaming (with SO) P2 Stage 2&3 Work 12/1 1/1 2/1 3/1 4/1 5/1 6/1 P1 Stage 1 Work P1 Stage 2&3 Work TR45.2 Nov TR45.2 Dec TR45.2 Feb TR45.2 Jan TR45.2 Mar TR45.2 PN App/Asgn Stage 1 submit Stage 2 submit KDDI GGRF and G95 G95 CC GSM Association /GGRF/G95 Phased Approach App Road Map App

More Related