html5-img
1 / 21

Status of 3G Interworking

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.

pascal
Download Presentation

Status of 3G Interworking

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. Status of 3G Interworking Lars Falk, Telia

  2. ETSI BRAN 3GPP SA1 MMAC/HiSWANa GSM Association IETF? More? Different companies offering proprietary solutions Bodies working on interworking

  3. Tight interworking Loose interworking See also ETSI TR 101 957 Two architecture alternatives

  4. 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

  5. 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

  6. 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

  7. 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

  8. 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

  9. Some issues fromETSI TR 101 957

  10. 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

  11. 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

  12. Long list derived from a 3GPP document Security requirements

  13. 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

  14. 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

  15. 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

  16. 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

  17. 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

  18. 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

  19. 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

  20. 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

  21. Study the issue within existing SG or TG? New SG? Wait? What will 802.11 do?

More Related