November 2001 Lars Falk, TeliaSlide 1 doc.: IEEE /617r1 Submission Status of 3G Interworking Lars Falk, Telia

November 2001 Lars Falk, TeliaSlide 2 doc.: IEEE /617r1 Submission Bodies working on interworking ETSI BRAN 3GPP SA1 MMAC/HiSWANa GSM Association IETF? More? Different companies offering proprietary solutions

November 2001 Lars Falk, TeliaSlide 3 doc.: IEEE /617r1 Submission Two architecture alternatives Tight interworking Loose interworking See also ETSI TR

November 2001 Lars Falk, TeliaSlide 4 doc.: IEEE /617r1 Submission Tight Interworking Iu Iur WLAN UTRAN UMTS Core Network APC RNS APT Tight interworking means that the WLAN network is connected directly to the UMTS core network, via e.g. Iu or Iub

November 2001 Lars Falk, TeliaSlide 5 doc.: IEEE /617r1 Submission Loose Interworking Loose interworking means interworking is done on an IP level, e.g. between AAA and Mobile IP on one side and HLR/HSS on the other

November 2001 Lars Falk, TeliaSlide 6 doc.: IEEE /617r1 Submission Reasons for Loose Interworking 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

November 2001 Lars Falk, TeliaSlide 7 doc.: IEEE /617r1 Submission Reasons for Loose Interworking, cont’d Probably cheaper Supports interworking with several types of cellular systems Possible to support several types of WLAN Established in the architecture of ETSI BRAN

November 2001 Lars Falk, TeliaSlide 8 doc.: IEEE /617r1 Submission ETSI BRAN 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)

November 2001 Lars Falk, TeliaSlide 9 doc.: IEEE /617r1 Submission Some issues from ETSI TR

November 2001 Lars Falk, TeliaSlide 10 doc.: IEEE /617r1 Submission High level requirements 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

November 2001 Lars Falk, TeliaSlide 11 doc.: IEEE /617r1 Submission Subscriber data 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

November 2001 Lars Falk, TeliaSlide 12 doc.: IEEE /617r1 Submission Security requirements Long list derived from a 3GPP document

November 2001 Lars Falk, TeliaSlide 13 doc.: IEEE /617r1 Submission WLAN User Equipment 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.

November 2001 Lars Falk, TeliaSlide 14 doc.: IEEE /617r1 Submission Mobility 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

November 2001 Lars Falk, TeliaSlide 15 doc.: IEEE /617r1 Submission QoS 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 DiffServ should be supported It should be possible for the operator to control/configure the mapping between IEEE 802.1p (priority bits) and DiffServ classes

November 2001 Lars Falk, TeliaSlide 16 doc.: IEEE /617r1 Submission Terminal aspects 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

November 2001 Lars Falk, TeliaSlide 17 doc.: IEEE /617r1 Submission Security 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

November 2001 Lars Falk, TeliaSlide 18 doc.: IEEE /617r1 Submission Mobility and handover 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

November 2001 Lars Falk, TeliaSlide 19 doc.: IEEE /617r1 Submission 3GPP 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

November 2001 Lars Falk, TeliaSlide 20 doc.: IEEE /617r1 Submission Levels of 3GPP SA1 approach 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

November 2001 Lars Falk, TeliaSlide 21 doc.: IEEE /617r1 Submission What will do? Study the issue within existing SG or TG? New SG? Wait?