[Docs] [txt|pdf] [Tracker] [Email] [Nits]
Versions: 00
INTERNET-DRAFT Charles Perkins
Working Group Nokia Research
July 30,2000 Hossam Afifi
expires 30 January 2001 INT Evry
Internet General Packet Radio Service (IGPRS); Service description
draft-afifi-igprs-00.txt
Status of this Memo
This document is an individual contribution for consideration by the
IPNG Working Group of the Internet Engineering Task Force. Comments
should be submitted to the mailing list.
Distribution of this memo is unlimited.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at:
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at:
http://www.ietf.org/shadow.html.
Abstract
We propose an architecture (IGPRS) for the integration of the IPv6
protocol in the GPRS infrastructure. The data and signalling
protocol suite will be based on mobile IPv6 protocol (instead of
the GTP protocol). This new infrastructure will take advantage of
the available internet protocols for routing and security. Since it
is targetted to co-exist with the GPRS, it is a partial translation
of MAP specifications to Internet protocols. This document uses some
of the GPRS Service document and some of its terminology.
The IGPRS interface will be complementary to GPRS protocols and can
co-exist with them. It represents hence a smooth migration to an all
IP network. A GPRS terminal that has IGPRS functionality will be
able to directly use the internet infrastructure for data and
signalling transmission.
A GPRS Base Station that has this additional functionality will be
able to translate all the traffic coming from an enhanced GPRS
terminal
Page 1 GPRS Interface to Mobile IPv6
to a conventional IPv6 protocol suite. IPv4 can be used by mobile
applications but the underlying infrastructure will be only based on
IPv6. Transition mechanisms should hence be used when IPv4 is
required.
Since a large legacy of management protocols is available and
necessary in the GPRS/GSM+2 infrastructure and since the GPRS data
protocols are designed to co-exist with the GSM, we propose an
architecture that supports mobile Ipv6 as the data protocol and
diameter as the main signalling protocol (AAA). In the boundaries we
propose to interface the internet protocols with the conventional
GPRS entities (e.g. HLRs, MSC/VLRs) in order to keep the necessary
user management consistency.
The resulting architecture is then composed of enhanced Ipv6 GPRS
terminals, enhanced GPRS Base stations and enhanced HLR/VLR
functionalities capable of dealing with Internet protocols.
Table of Contents
----------------------
1. Introduction
2. Abbreviations and terminology
3. Protocol Overview
4. Packet formats
5. Procedures
6. Security considerations
7. Security Function
1 . Introduction and scope
This document gives the service description of the Internet Based
GPRS system (IGPRS) that represents an evolution of the current GPRS
service as defined in the document [GPRS]. It is hence mainly
compliant with the current GPRS service description principles. It
gives the procedures and functionalities that have to be implemented
in the terminals and in the network in order to operate an IPv4/IPv6
based mobile public data network. This system is designed to run in
presence of the conventional GPRS and GSM systems.
The base protocol in this architecture is IPv6 and does not at all
preclude IPv4 in the mobile node. However, all mobility and
signalling procedures are achieved using the v6 version only. IGPRS
fully relies on the normal layer 2 GPRS protocols and eventually
data compression. The following sections give the detailed operation
of the IGPRS system. The rest of this document is organized as
follows. Section 2 gives some definitions and abbreviations that
will be frequently used in the subsequent sections. Section 3
defines the protocol main entities and states describing a mobile
node and their relation to Mobile IPv6 states. In Section 4 we
describe the packet formats. Section 5 gives the procedures and
transitions between the protocol functions. Section 6 gives the
security functions necessary for user authentication.
2 . Abbreviations and terminology
Page 2 GPRS Interface to Mobile IPv6
DNS Domain Name Service
IGSS Internet GPRS Support Server, it must be a v6 Home Agent.
IMSI International Mobile Subscriber Identity
NAI Network Access Identifier
MIPv6 Mobile IP v6
MN Mobile Node
PCB Protocol Control Block. Information associated with a node.
PLMN Public Land Mobile Network
RA Routing Area, A space of administration for a single Home Agent.
RAC Routing Area Code; IPv6 Prefix code
RAI Routing Area Identity; The canonical Name of the router
responsible of the RAC
RLC Radio Link Control
TLLI Temporary Logical Link Identity
TMSI Temporary Mobile Subscriber Identity Regional Registration
Identity
The GPRS architecture is mainly composed of a mobile node (MS), a
base station (BSS), a home agent (SGSN) and databases (HLR). Most of
entities in the IGPRS protocol suite are the same as defined in the
GPRS infrastructure except for: IGSS, that replaces the SGSN. It is
a Home Agent running Ipv6 with additional Diameter, DNS, routing and
security functionalities. It can co-exist with an SGSN node. BSS,
is the same as in the GPRS network except that it implements
IPv4/IPv6 routing functionalities. A BSS may represent a group of
layer 2 bridging equipments. It may be capable of header
compression/decompression facilities and could be based on a
connection oriented layer 2 protocol.
The main architecture of this document is based on the integration
of the Home Agent entity in the SGSN. A second alternative is
possible with the home agent being embedded in the GGSN. We do not
consider this architecture in this document and we leave it for
further study.
3 . Protocol Overview
In this section we present the main entities implied in IGPRS.
Page 3 GPRS Interface to Mobile IPv6
+--------+ +------+ +------+ +--------+-----+ +--------+-----+
|IP/MIP6 | | IP6 | | MIP6 | |Diameter| MAP | |DIAMETER| MAP |
|------- | | | | | | | | | | |
| LLC | | LLC | +------+ +--------+-----+ +--------+-----+
| RLC | | RLC |
| MAC | | MAC |
| GSM/RF | |GSM/RF|
+--------+ +------+
MN BSS IGSS HLR MSC/VLR(optional)
3 . 1 . Protocol Entities
IPv6 is implemented on the physical layer and layer 2 of the GPRS
protocol. We identify the Mobile node MN, BSS, IGSS, HLR interface
and MSC/VLR interface as the entities representing IGPRS. The MN
has some interactions with the BSS and others with the IGSS. The BSS
is responsible of informing the MN of its location area (the
subnetwork in IPv6) and of its Home Agent identity. The IGSS
initiates security functions and updates the HLR with any necessary
mobility management procedure. The optional dialogue between the
IGSS and MSC/VLR is for further study. Mobile IPv6 is only seen
between the MN and the IGSS. The rest of the entities are not part
of the mobility process. We describe in the following section the
interaction of the IPv6 layer with layer 2 states. Some procedures
in the IGPRS proposal are timer based and others location based. The
first procedures are necessary to save the air interface resources
and to rapidely detect any MN disappear. The second set of
procedures correspond to mobility management at the network level.
The Mobile Node (MN)
The v6 Mobility Management (MM) activities related to a IGPRS
subscriber are characterized by one of three different states. Each
state describes a certain level of functionality and information
allocated. It is to be noted that the MN will keep a link local
address whenever it has to establish any pre-authentication
procedure. Once it has to send user data it should obtain a valid
address. This will be explained later. The IPv6 layer will be able
to detect at each time the current state of the entity along with
the related state variables and to achieve the necessary procedures.
IDLE (IGPRS) State
In GPRS IDLE state, the subscriber is not attached to the IGPRS
mobility management. The MN and IGSS context hold no valid routing
information for the subscriber. The subscriber-related mobility
management procedures are not performed. The MN does not have a home
agent (IGSS) neither. Since the MN listens to multicast layer1
physical information it can perform locally PLMN selection and IGPRS
cell selection and re-selection processes. Data transmission to and
from the mobile node as well as the paging of the subscriber are not
possible. The GPRS MN is seen as not reachable in this case. From
an IP/IPv6 point of view the node does not have any valid address
(except a link local), valid default router or valid home agent
information (routing area). In order to establish contexts in the MN
and the IGSS, the MN shall perform the IGPRS Attach procedure
explained in the Procedures section.
STANDBY State
Page 4 GPRS Interface to Mobile IPv6
In STANDBY state, the subscriber is attached to IGPRS mobility
management. The MN and IGSS have established contexts for the
subscriber's IMSI/NAI. Pages for data or signalling information may
be received. User IPv6 reception and transmission are not possible
in this state. The MN performs IGPRS Home Agent selection and IGPRS
cell selection and re-selection locally. The MN listens on the
broadcast channel to learn about the router advertisement and hence
to know its prefix and whether it is still in the same routing area
(HA) or not. The MN executes mobility management procedures to
inform the IGSS when it has entered a new HA zone. This includes MIP
procedures. The MN does not inform the IGSS on a change of cell in
the same HA zone. Therefore, the location information in the IGSS
context contains only the identification of the MN but not its cell
location. The MN may initiate activation or deactivation of contexts
while in STANDBY state. A context shall be activated before data can
be transmitted or received for this PCB context. The IGSS may have
to send data or signalling information to an MN in STANDBY state.
Paging in the STANDBY state is accomplished by Neighbour
Sollicitation messages sent from the IGSS or BSS. The suffix is
simply set to the IMSI identifier. It should be noted that no DAD is
to be done on a IGPRS network. Paging may not be an efficient way
to reach the MN but the procedure should be implemented to solve at
minimum, emergency situations. An alternative to paging is to wait
until the node subscribes with a new IGSS or updates the old one
through the periodic routing updates as described in the following
sections.
The MN or the network may initiate the IGPRS Detach procedure to
move to the IDLE state. After expiry of the mobile reachable timer
the IGSS may perform an implicit detach in order to return in the
IGSS to IDLE state.
READY State
In READY state, the IGSS updates the MN context with its subnetwork
(prefix). The MN performs mobility management procedures to provide
the network with the actual selected cell (prefix). IGPRS cell
selection and re-selection is done locally by the MN, or may
optionally be controlled by the network. The MN Prefix is sent
periodically to the IGSS via the BSS (the procedure can be achieved
with hob-by-hop Options or ICMPv6 messages). When a mobile node
makes a handover to a new cell, the default router may or may not
change according to the network topology. Two cells may be in the
same routing area. However it is good to know the cell identity
(that would correspond to some layer two details) for a better
interaction with the fixed network. The mobile node learns this
information from the radio layer and forwards it to the BSS and IGSS
( through an ICMPv6 or Destination Option). The MN may send and
receive Internet PDUs in this state. The network initiates no IGPRS
pages for an MN in READY state The IGSS transfers downlink data to
the BSS responsible for the subscriber's actual IGPRS cell.
Regardless if a radio resource is allocated to the subscriber or
not, the MN remains in the READY state even when there is no data
being communicated. The READY state is supervised by a timer. An MN
context moves from READY state to STANDBY state when the READY timer
expires. In order to move from READY state to IDLE state, the MN
initiates the IGPRS Detach procedure. This means that the IPv6
global address is no more valid.
Page 5 GPRS Interface to Mobile IPv6
Mobility management in the IGSS side
This section describes the additional states that have to be
maintained relating IPv6 to the lower layer. The states are mainly
related to timers. Some states are kept in both the MN and IGSS.
READY Timer Function
The READY timer function maintains the READY timer in the MN and
IGSS. The READY timer controls the time an MN remains in READY state
in the MN and the IGSS. The READY timer shall be reset and begin
running in the MN when a packet is transmitted, and in the IGSS when
it is correctly received. When the READY timer expires, the MN and
IGSS contexts shall return to STANDBY state. The length of the
READY timer shall be the same in the MN and IGSS. The initial length
of the READY timer shall be defined by a default value. The IGSS,
and only the IGSS, may change the length of the READY timer by
transmitting a new value in the Attach Accept, Routing Area Update
Accept. If the READY timer length is set to zero, the MN shall
immediately be forced into STANDBY state.
Periodic RA Update Timer Function
Routing Area Update functionality is directly coupled with the MIPv6
management. The Periodic RA Update Timer function monitors the
periodic RA update procedure in the MN. The periodic RA update
timer is unique within an RA. Upon expiry of the periodic RA update
timer, the MN shall start a periodic routing area update procedure.
Mobile Reachable Timer Function
The Mobile Reachable Timer function monitors the periodic RA update
procedure in the IGSS. The mobile reachable timer shall be slightly
longer than the periodic RA update timer used by an MN. The mobile
reachable timer is stopped when the READY state is entered. The
mobile reachable timer is reset and started when the state returns
to STANDBY. If the mobile reachable timer expires, the IGSS shall
stop sending IGPRS paging messages to the MN, but other features may
happen immediately.
4 . Messages Formats
This section describes the necessary packet and headers format for
IGPRS infrastructure.
We identify messages from the MN to the IGSS. From the IGSS to the
HLR and vice-versa.
Inter IGSS Diameter Extensions:
IGSS to HLR Diameter Messages:
IPv6 Hop-by-Hop IGSS option:
IPv6 Router Sollicitations Authentication Header and options:
5 . IGPRS Procedures and Functions
In this section we describe the actions that entities have to take
to implement the mobility management for IGPRS. We start by
describing the functions activated in IPv6 due to the state
transitions occuring in both MN and IGSS. We also explain the
procedures that are used to accomplish the routing update (change of
HA and of default router).
Page 6 GPRS Interface to Mobile IPv6
5 . 1 . State transition in the MN and IGSS
This section gives details on the changes that will happen when a MN
goes from one state to the other. These state information are
obtained from the lower layers.
The movement from one state to the next is dependent on the current
state (IDLE, STANDBY, or READY) and the event occurred (e.g., IGPRS
attach). We describe the IPv6 necessary actions when such a
transition happens.
+-------+ +-------+
| IDLE | | IDLE |
+-------+ /+-------+
/ \ // \
\|/ /|\ /\|/ /|\
| | / | |
\ / | \ /
+-------+ | +-------+
| READY | /|\ | READY |
+-------+ | +-------+
/ \ | / \
\|/ /|\ | \|/ /|\
| | | | |
\ / \ \ /
+-------+ \ +-------+
|STANDBY| \ |STANDBY|
+-------+ +-------+
MM states diagrams for MN and IGSS
Moving from IDLE to READY:
- IGPRS Attach: The MN requests access and a logical link to an IGSS
is initiated.
Moving from STANDBY to IDLE:
- Implicit Detach: The MN and the IGSS shall return to IDLE.
- Cancel Location: The IGSS receives a MAP Cancel Location message
from the HLR (through the Diameter extensions).
Moving from STANDBY to READY:
- PDU transmission: The MN sends a packet to the IGSS, possibly in
response to a page.
- PDU reception: The IGSS receives an IPv6 from the MN.
Moving from READY to STANDBY:
- READY timer expiry: The MN and the IGSS return to STANDBY state.
- Force to STANDBY: The IGSS indicates an immediate return to
STANDBY state before the READY timer expires.
- Abnormal RLC condition: The IGSS returns to STANDBY state in case
of
Page 7 GPRS Interface to Mobile IPv6
delivery problems on the radio interface or in case of irrecoverable
disruption of a radio transmission.
Moving from READY to IDLE:
- IGPRS Detach: The MN or the network requests to return to IDLE
state. The IGSS may delete the MN from its entries.
- Cancel Location: The IGSS receives a MAP Cancel Location message
from the HLR.
Attach Function
A IGPRS attach is made to the IGSS. A IGPRS-attached MN makes
NAI/IMSI attach via the IGSS. In the attach procedure, the MN shall
provide its identity and an indication of which type of attach that
is to be executed. The regional Registration should be used as much
as possible to prevent too many authentication exchanges with the
home IGSS. A Temporary identification should be used (P-TMSI) After
having executed the IGPRS attach, the MN is in READY state and the
IGSS also.
The detailed procedure of an attach function is described here-
after:
The MN initiates the attach procedure by sending an ICMPv6 router
sollicitation message. The BSS, using the DIAMETER Protocol Direct
Reboot Indication (IMSI or P-TMSI and old RAI, old P-TMSI Signature)
sends a message to the IGSS. On the point to point wireless link the
MN sends its IMSI for authentication. NAI/IMSI shall be included if
the MN does not have a valid P-TMSI available. If the MN has a valid
P-TMSI, then P-TMSI and the old RAI (Prefix) associated with P-TMSI
shall be included in the ICMPv6 packet. If the MN identifies itself
with P-TMSI and the IGSS has changed since detach, the new IGSS
sends an Identification Request (P-TMSI, old RAI, old P-TMSI
Signature) diameter message to the old IGSS to request the IMSI. The
old IGSS responds with Identification Response (NAI/IMSI,
Authentication Triplets). If the MN is not known in the old IGSS,
the old IGSS responds with an appropriate error cause. The old IGSS
also validates the old P-TMSI Signature and responds with an
appropriate error cause if it does not match the value stored in the
old IGSS. If the MN is unknown in both the old and new IGSS, the
IGSS sends a DIAMETER Home-Agent-MIP-Request (Identity Type = IMSI)
to the BSS. The MN responds and the BSS forwards with Identity
Response (NAI/IMSI).
If the IGSS address has changed since the IGPRS detach, or if it is
the very first attach, then the IGSS informs the HLR: The IGSS
sends an Update Location (IGSS IPv6 Address, NAI/IMSI) to the HLR
through Diameter extensions. The HLR sends Cancel Location (IMSI,
Cancellation Type) to the old IGSS with Cancellation Type set to
Update Procedure. The old IGSS acknowledges with Cancel Location
Ack (IMSI). If there are any ongoing procedures for that MN, the old
IGSS shall wait until these procedures are finished before removing
the contexts. The HLR sends Insert Subscriber Data (IMSI, IGPRS
subscription data) to the new IGSS. The new IGSS validates the MN
presence in the (new) RA. If due to regional subscription
restrictions the MN is not allowed to attach in the RA, the IGSS
rejects the Attach Request with an appropriate cause, and may return
an Insert Subscriber Data Ack (IMSI, <IGSS Area Restricted>) message
to the HLR. If subscription checking fails for other reasons, the
IGSS
Page 8 GPRS Interface to Mobile IPv6
rejects the Attach Request with an appropriate cause and returns an
Insert Subscriber Data Ack (IMSI, Cause) message to the HLR. If all
checks are successful then the IGSS constructs a context for the MN
and returns an Insert Subscriber Data Ack (IMSI) message to the HLR.
The HLR acknowledges the Update Location message by sending an
Update Location Ack to the SGSN after the cancelling of old context
and insertion of new context are finished. If the Update Location is
rejected by the HLR, the IGSS rejects the Attach Request from the MS
with an appropriate cause. If the Attach Request cannot be
accepted, the IGSS returns an Attach Reject (IMSI, Cause) message to
the MN.
Detach Function
The Detach function allows an MN to inform the network that it wants
to make a IGPRS and/or NAI/IMSI detach, and it allows the network to
inform an MN that it has been IGPRS-detached or IMSI-detached by the
network. The only proposed detach procedure is: - IGPRS detach;
The MN is detached from IGPRS either explicitly or implicitly: -
Explicit detach: The network or the MN explicitly requests detach.
- Implicit detach: The network detaches the MN, without notifying
the MN, a configuration-dependent time after the mobile reachable
timer expired, or after an irrecoverable radio error causes
disconnection of the logical link. In the explicit detach case, a
Detach Request (Cause) is sent by the IGSS to the MN, or by the MN
to the IGSS.
5 . 2 Mobility Management procedures
Cell Update Procedure
A cell update takes place when the MN enters a new cell inside the
current RA and the MN is in READY state. If the RA has changed, a
routing area update is executed instead of a cell update. The MN
performs the cell update procedure by sending an uplink packet of
any type containing the MN identity to the IGSS with a Hop-by-Hop
option. In the direction towards the IGSS, the BSS shall add the
Cell Global Identity including RAC to all packets. A cell update is
any correctly received and valid IPv6 PDU. The IGSS records this
change of cell so that further traffic directed towards the MN is
conveyed over the new cell.
Routing Area Update Procedure
A routing area update takes place when a IGPRS-attached MN detects
that it has entered a new RA i.e a different Home Agent domain, when
the periodic RA update timer has expired, or when a suspended MN is
not resumed by the BSS. The IGSS detects that it is the same sub-
network. In this case, the IGSS has the necessary information about
the MN and there is no need to inform HLR about the new MN location.
A periodic RA update is always an intra IGSS routing area update.
Intra IGSS Routing Area Update
The Intra IGSS Routing Area Update procedure consists in a change of
the default router for the MN while keeping the same HA. The MN
sends a Routing Area Update Request (it is done via a v6 binding
update) (old RAI, old P-TMSI Signature, Update Type) to the IGSS.
Update Type shall indicate RA update or periodic RA update. The BSS
shall add the Cell Identity as a Hop-by-hop option. The IGSS
validates
Page 9 GPRS Interface to Mobile IPv6
the MN presence in the new RA (sub-network). If due to regional
subscription restrictions the MN is not allowed to be attached in
the RA, or if subscription checking fails, then the IGSS rejects the
routing area update. If all checks are successful then the IGSS
updates the MN record. A new P-TMSI may be allocated. A
confirmation is sent back to the mobile node (P-TMSI, P-TMSI
Signature). If P-TMSI was reallocated, the MN acknowledges the new
P-TMSI by returning a routing Area Update Complete AVP to the IGSS.
If the routing area update procedure fails a maximum allowable
number of times, or if the IGSS returns a routing Area Update Reject
(Cause) AVP, the MN shall enter IDLE state.
Inter IGSS Routing Area Update
The Inter IGSS Routing Area Update procedure is explained in the
following list. It consists in a change in the HA for the mobile
node. The MN sends a Routing Area Update Request (binding update
with the old HA address, old P-TMSI Signature, Update Type) to the
new IGSS. Update Type shall indicate RA update or periodic RA
update. The BSS shall add the Cell Global Identity in the Hop-by-hop
option. The new IGSS sends Diameter AVP containing IGSS Context
Request (old RAI, TLLI, old P-TMSI Signature, New IGSS Address) to
the old IGSS for this MN. The old IGSS validates the old P-TMSI
Signature and responds with an appropriate error cause if it does
not match the value stored in the old IGSS. This should initiate the
security functions in the new IGSS. If the security functions
authenticate the MN correctly, the new IGSS shall send an IGSS
Context Request (old RAI, TLLI, MN Validated, New IGSS Address)
Diameter message to the old IGSS. MN Validated indicates that the
new SGSN has authenticated the MN. These procedures are described in
the context of the Diameter extensions in details. If the old P-TMSI
Signature was valid or if the new IGSS indicates that it has
authenticated the MN, the old IGSS stops assigning forwarding the
traffic downlink, and responds with IGSS Context Response. If the MN
is not known in the old IGSS, the old IGSS responds with an
appropriate error cause. Contrary to the original GPRS mechanism
where the SGSN adds a new entity in the chain, the IGSS which is a
home agent cannot be changed while active contexts are present. In
the absence of active contexts the inter IGSS procedure can be
applied. A timer is triggered in the old IGSS.
The new IGSS sends an IGSS Context Acknowledge message in the
appropriate Diameter format to the old IGSS. This informs the old
IGSS that the new IGSS is ready to receive data packets belonging to
MN and the necessary DNS procedure are executed to change the MN
prefix to the one belonging to the new IGSS. The old IGSS marks in
its context that the information in the HLR is invalid.
If the security functions do not authenticate the MN correctly,
then the routing area update shall be rejected, and the new IGSS
shall send a reject indication to the old IGSS. The old IGSS shall
continue as if the IGSS Context Request was never received. The new
IGSS updates the MN entry (new IGSS Address HA) The new IGSS informs
the HLR of the change by sending Update Location (IGSS v6 address,
IMSI) to the HLR. The HLR sends Cancel Location (IMSI, Cancellation
Type) to the old IGSS with Cancellation Type set to Update Procedure
(This is done with the Diameter protocol). Then the old IGSS removes
the contexts. Otherwise, the contexts are removed only when the
timer expires. This allows the old IGSS to ensure that the contexts
are kept in the old SGSN in case the MN initiates another inter IGSS
routing area update before completing the ongoing routing area
update to the new IGSS. The old IGSS acknowledges with Cancel
Location
Page 10 GPRS Interface to Mobile IPv6
Ack (IMSI) The HLR sends Insert Subscriber Data (IMSI, IGPRS
subscription data) to the new IGSS. The new IGSS validates the MN
presence in the (new) RA. If due to regional subscription
restrictions the MN is not allowed to be attached in the RA, the
IGSS rejects the Routing Area Update Request with an appropriate
cause, and may return an Insert Subscriber Data Ack message to the
HLR. If all checks are successful then the IGSS constructs a context
for the MN and returns an Insert Subscriber Data Ack (IMSI) message
to the HLR. The HLR acknowledges the Update Location by sending
Update Location Ack (IMSI) to the new IGSS. The new IGSS validates
the MN presence in the new RA. If due to roaming restrictions the MN
is not allowed to be attached in the IGSS, or if subscription
checking fails, then the new IGSS rejects the routing area update
with an appropriate cause. If all checks are successful then the new
IGSS constructs contexts for the MN. The new IGSS responds to the MN
with Routing Area Update Accept (P-TMSI, P-TMSI Signature). The MN
acknowledges the new P-TMSI by returning a Routing Area Update
Complete message to the IGSS. In the case of a rejected routing area
update operation, due to regional subscription or roaming
restrictions, the new IGSS shall not construct a context. A reject
shall be returned to the MN with an appropriate cause. The MN shall
not re-attempt a routing area update to that RA. The RAI value shall
be deleted when the MN is powered-up.
6 . Security Considerations
The Security function:
- Guards against unauthorised IGPRS service usage (authentication
and service request validation).
- Provides user identity confidentiality (temporary identification-
Regional Registration, and ciphering).
- Provides user data confidentiality (ciphering).
Authentication of Subscriber
Authentication procedures already defined in GSM and in the Diameter
strong authentication shall be used, with the distinction that the
procedures are executed from the IGSS. The IGSS may act according to
Diameter specifications as a proxy in a chain. The IGPRS
Authentication procedure performs subscriber authentication, or
selection of the ciphering algorithm and the synchronization of the
start of ciphering, or both. Authentication triplets are stored in
the IGSS. The Authentication procedure is explained in the following
list. If the IGSS does not have previously stored authentication
triplets, a Send Authentication Info (IMSI) message is sent to the
HLR through the Diameter protocol proxying procedures. The HLR
responds with a Send Authentication Info Ack (Authentication
Triplets) message. Each Authentication Triplet includes RAND, SRES,
and Kc. The IGSS sends an Authentication and Ciphering Request
(RAND, CKSN, Ciphering Algorithm) message to the MN. The MN
responds with an Authentication and Ciphering Response message
through Diameter extensions. The MN starts ciphering after sending
the Authentication and Ciphering Response message. The IGSS starts
ciphering when a valid Authentication and Ciphering Response is
received from the MN. In the routing area update case, if ciphering
was used before the routing area update, and if the Authentication
procedure is omitted, then the IGSS shall resume ciphering with the
same
Page 11 GPRS Interface to Mobile IPv6
algorithm when a ciphered Routing Area Update Accept Diameter
message is sent, and the MN shall resume ciphering when a ciphered
Routing Area Update Accept Diameter message is received. User
Identity Confidentiality A Temporary Logical Link Identity (TLLI)
identifies a IGPRS user. The relationship between TLLI and IMSI is
known only in the MN and in the IGSS. TLLI is derived from the P-
TMSI allocated by the IGSS or built by the MN. The IGSS may
reallocate the P-TMSI at any time when the MN is in READY state. The
reallocation procedure can be performed by the P-TMSI Reallocation
procedure, or it can be included in the Attach or Routing Area
Update Diameter procedures.
P-TMSI Signature
P-TMSI Signature is optionally sent by the IGSS to the MN in Attach
Accept and Routing Area Update Accept Diameter messages. If the P-
TMSI Signature has been sent by the IGSS to the MN since the current
P-TMSI was allocated, then the MN shall include the P-TMSI Signature
in the next Routing Area Update Request and Attach Request for
identification checking purposes. In the Attach and Routing Area
Update procedures, the IGSS shall compare the P-TMSI Signature sent
by the MN with the signature stored in the IGSS. If the values do
not match, the IGSS should use the security functions to
authenticate the MN. If the values match or if the P-TMSI Signature
is missing, the IGSS may use the security functions to authenticate
the MN. The P-TMSI Signature parameter has only local significance
in the IGSS that allocated the signature. If ciphering is supported
by the network, the IGSS shall send the P-TMSI Signature ciphered to
the MS. Routing Area Update Request and Attach Request, into which
the MN includes the P-TMSI Signature, are not ciphered.
IMEI
This is the identification of the terminal. It can be required by a
given operator. It is hence taken into consideration in the security
functions.
7 . Security Functions
P-TMSI Reallocation Procedure
This is the procedure by which the MN will obtain a temporary key in
the authentication domain of the new IGSS. Diameter messages will
help the exchange of keys between the original and the new IGSS. At
the end of the procedure the MN should receive a valid P-TMSI using
the IKE protocol.
Identity Check Procedure
The Identity Check procedure is explained in the following list.
1) The IGSS sends Identity Request (Identity Type) to the MN. The MN
responds with Identity Response (Mobile Identity).
2) If the IGSS decides to check the IMEI, it sends Check IMEI (IMEI)
Diameter message to the BSS that translates it and forwards it to
the MN.
0n) References
Page 12 GPRS Interface to Mobile IPv6
[CHAP] CHAP, PPP Challenge Handshake Authentication Protocol. rfc-
1994.
[GPRS] Draft ETSI EN 301 344 V6.6.0 (2000-02) European Standard
(Telecommunications series) Digital cellular telecommunications
system (Phase 2+); General Packet Radio Service (GPRS); Service
description; Stage 2 (GSM 03.60 version 6.6.0 Release 1997)
[ADDRCONF] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
Authors may be reached at
charliep@iprg.nokia.com
hossam.afifi@int-evry.fr
Page 13 GPRS Interface to Mobile IPv6
Html markup produced by rfcmarkup 1.129d, available from
https://tools.ietf.org/tools/rfcmarkup/