210 likes | 381 Views
Status of 3G Interworking. Lars Falk, Telia. ETSI BRAN 3GPP SA1 MMAC/HiSWANa GSM Association IETF? More? Different companies offering proprietary solutions. Bodies working on interworking. Tight interworking Loose interworking See also ETSI TR 101 957. Two architecture alternatives.
E N D
Status of 3G Interworking Lars Falk, Telia
ETSI BRAN 3GPP SA1 MMAC/HiSWANa GSM Association IETF? More? Different companies offering proprietary solutions Bodies working on interworking
Tight interworking Loose interworking See also ETSI TR 101 957 Two architecture alternatives
UMTS Core Network Iu Iu Iu UTRAN WLAN RNS RNS APC Iur APT APT Tight Interworking Tight interworking means that the WLAN network is connecteddirectly to the UMTS core network, via e.g. Iu or Iub
Loose Interworking Loose interworking means interworking is done onan IP level, e.g. between AAA and Mobile IP on oneside and HLR/HSS on the other
The loose interworking avoids impact on 3G core network nodes Tight interworking means that full 3G signaling would have to be mapped on the WLAN radio interface, i.e. a complex solution Possible to support several types of WLAN Possible to use present WLAN equipment Tight interworking may lead to scalability problems Reasons for Loose Interworking
Probably cheaper Supports interworking with several types of cellular systems Possible to support several types of WLAN Established in the architecture of ETSI BRAN Reasons for Loose Interworking, cont’d
Loose interworking first Phased approach, will release two stages R1: authentication, subscriber handling, security functions, only best effort, basic charging Formal approval at BRAN#28 (April) R2: mobility support and service integration WA: Formal approval at BRAN#30 (October) ETSI BRAN
Support different environments (home, corporate and public) and different administrative domains Partnership or roaming agreements between a UMTS operator and a WLAN network shall be supported High level requirements
The user can have a subscription for WLAN solely or for the combination WLAN and 3G The subscriber identification shall be in such a format that it can be used in just WLANs or in WLANs that are interworking with 3G systems The subscriber database for interworking between the WLAN and the 3G network, could be just one that is shared or there could be one for each network that share the subscribers' security association Subscriber data requirements
Long list derived from a 3GPP document Security requirements
It shall be possible to control access to WLAN specific data (protocol intervention). It shall not be possible to access WLAN specific data that is only intended to be used for security purposes. It shall be difficult to change the identifier. WLAN User Equipment Requirements
Handover from WLAN to 3G and vice versa shall be supported A handover from WLAN to 3G will need to be service/application specific The user should be notified of any possible degradation of the provided quality of service due to change of access network Mobility requirements
Should be subject to user's subscription It should be possible for a WLAN network operator to monitor the QoS provided to the users It should be possible to charge a user based on the level of QoS provided and on the QoS subscribed QoS authorization should be performed locally The mapping between IEEE 802.1p priority levels (0-7 bits) and IP DiffServshould be supported It should be possible for the operator to control/configure the mapping between IEEE 802.1p (priority bits) and DiffServ classes QoS requirements
The following points should be considered: Usage and handling of the (U)SIM, if applicable Communication of two mechanically different parts, UMTS UE and WLAN MT, within a single terminal The placement of common functions, like handover Terminal aspects
Separate AAA server or integrated with HLR/HSS? Different alternatives for user information coordination User identification: NAI, IMSI or IMSI in NAI? UICC or not? Telia: Support both alternatives Security
Base case: AAA roaming, i.e. reauthentication when moving to different technologies, leads to drop of actice sessions Enhanced mobility: e.g. via Mobile IP or SIP Mobility only visible to upper layers, invisible to access network Mobility and handover
SA1 will produce requirements, SA2 architecture One meeting held by SA1 Report should be finalised at SA1#16 (June?) Starting point is a 5 level approach 3GPP
Level 1 : Common billing and customer care Level 2 : Common access control and charging (including UTRAN level of security for WLAN) Level 3 : Access to all UMTS PS based services Level 4 : Service continuity between accesses Level 5 : Seamless mobility Levels of 3GPP SA1 approach
Study the issue within existing SG or TG? New SG? Wait? What will 802.11 do?