V irtual H ome E nvironment ( VHE ) and O pen S ervices A ccess ( OSA ) - an overview

1. Virtual Home Environment (VHE)andOpen Services Access (OSA)- an overview Jörg Swetina, SIEMENS AG Tel: +43 51707 21422 mobile: +43 676 4912429 mail: joerg.swetina@siemens.at

2. Main Aspects of VHE and OSA VHE The Virtual Home Environment (VHE) is a concept for • a Personal Service Environment (PSE) • supports services personalisation, multiple user profiles • PSE portability across network boundaries and between terminals. • Home- and visited network, different access networks (e.g. mobile, fixed, IP), from one terminal to the other • service creation based on standardised toolsets e.g. • CAMEL, MExE, SAT, OSA OSA The Open Services Acess (OSA) is a toolkit within VHE that • enables service providers to make use of network functionality • call (session) control, management of conferences, location information • offers an open standardised OO interface (API) to applications • Application authentication/authorisation, Discovery of service capabilties • User Status (Profile, Terminal), Call Control ... • Extensible, ObjectOriented (specified in IDL), Implementation-independent

3. Contents • The VHE concept • Goals of VHE • Roles within VHE • Toolsets for realisation • VHE “To-Do” list • The OSA tool • Goals and driving force behind OSA • Principles • Architectural considerations • Supported functions • OSA “To-Do” list

4. The VHE concept - Goals • Users are consistently presented withthe same personalised features, User Interface customisation and services in whatever network and whatever terminal (within the capabilities of the terminal and the network), wherever the user may be located • Provide the ability to build services using a standardised application interface(makes use of capabilities of e.g. MExE, OSA)

5. USER Personal Provided and Value Added Home Service controlled by Service Provider Environment Environment Contains 1:N User General User N:N Profile Preferences and Subscribed Service Contains 1:N HE Value Added Service Service Profile, i.e. Service Provider Commercial relationshipwith Home Environment:the HE Value AddedService Provider offers services to the user, mayuse facilities of PSE Specific Service Preferences The set of services from the Users point of view Roles in the Virtual Home Environment (I) Personal ServiceEnvironment: = entirety of services andpersonalisation informationof a User, managed by HE Value Added ServiceProvider: offers services directly to the user. Services not part of HE.(But HE may support discovery and accessof local services) Commercial relationshipwith the user:the Home Environment provides and controlsservices to the userin a consistent manner User Profileenables a user to manageservices according todifferent situations/needse.g. at home or at work Services, manged by HEmobility of the service andservice personalisation(storage / recovery)supported by HE

6. Roles in the Virtual Home Environment (II) • the user’s Home Environment (HE) • comprises of at least one UMTS connectivity provider (operator) • provides the user with an identity (IMSI ?) and one or more addresses (MSISDN, URL) • controls access to services depending on the location of the user and serving network • responsible for overall provision of services • responsible for management and integrity of User Profiles • a Home Environment Value Added Service Provider (HE-VASP) • has a commercial (trust-) relationship with HE - allowing e.g. “one-stop-billing” • runs services which are supported by the HE and which are supporting the HE • Services in the user‘s Home Environment • may access network capabilities (OSA) or run in “operator’s Domain” on terminals (MExE) • may save personalisation data in a - HE managed - User Profile. • one or more User Profile(s) • consists of data appliccable to all services (e.g. language) and service specific data (e.g. provision / activation state), actual terminal capabilities... • access to and modification of the User Profile is - safely - controlled and maintained by HE • multiple User Profiles group personalisation data according different communication needs

7. Toolsets for the realisation of VHE HEVASPs OSAServices HE VASP VASP HE VASP Download Applicationsand transport of user data OSA API HE non HE MExEServices SATServices SAT Server Transport of user data(WAP, WWW, FTP...) Synchronise User Profile OSA GW non standardised interfaces CAMELServices ??? e.g. SAT or MExE Environment Internet CSE

8. What remains to be done in VHE ? VHE To-Do list: • clear definition of „Home Environment“ (one or more home operators?) • Definition of User Profile(s): structure, mandatory content, involved entities, synchronisation mechanisms • Mechanisms and entities for retrieving terminal capabilities and for backup of terminal-based services • Toolset Interworking: User profile, charging, traceability • Services: Discovery for home-and local services, service identification Specifications • 3G TS 22.121 (stage 1) responsibility: TSG SA 1, rapporteur: Fujitsu • 3G TS 23.127 (stage 2) responsibility: TSG SA 2, rapporteur: Ericsson

9. The VHE concept • Goals of VHE • Roles within VHE • Toolsets for realisation • VHE “To-Do” list • The OSA tool • Goals and driving force behind OSA • Principles • Architectural considerations • Supported functions • OSA “To-Do” list

10. The OSA toolkit - Goals • Define a HE controlled access mechanism that enables service providers to make use of network functionality through an open standardised interface, i.e. the OSA API. • Allow applications to become independent from the underlying network technology and vendor-specific interfaces. • Secure, Scalable, Extensible

11. Driving Forces behind OSA • 3rd party service providers • simple access to Telco-network functionality • service provision independent from type of Network • allows addressing specific customer segments • Regulator • enable open, non-discriminatory secure access to network functionality • improvement of competition • Network Operator • simplified Service Creation (compared e.g. with IN/CAMEL services) • seamless interworking across network technologies • investment protection (re-use of existing resources e.g. CAMEL) • Supplier • new products • new business opportunities • prerequisite to be compliant with UMTS standard

12. Application server Application discovery OSA interface OpenServicesAccess Interface class User Location Call control framework Service capability server(s) WAP HLR CSE Servers E.g. Location server Gateway,Push-Proxy MExE server SAT server OSA principles Applications executing onan Application Servercommunicate via OSA APIwith framework and service capability servers The Framework cares for Authentication/Authorisationof Applications. Additionally SC Servers can Register their SC Features Service Capability Servers provide SC Features(=bundle of interface classes) to Applications. SCSs arelogical, not physical entities Different kind of network entities / servers realise the functions physically, which are offered by SC Servers through their SC Features

13. OSA architectural considerations (I)Relation between SCSs and physical entities Option 1: SCSs and network functional entities implemented in separate physical entities a) OSA in one gateway b) OSA in several gateways Option 2: SCSs and network functional entities implemented in the same physical entity Option 3: Hybrid model (combination of 1 and 2)

14. OSA API Application using network services Data base Application system Enterprise Domain OSA architectural considerations (II)the Application‘s view CSCF VoIP Switch PSTN/ PLMN OSA Gateway SCP e.g. CORBA HLR Telecom Network Domain

15. OSA architectural considerations (III)Home- vs. Local IM services support (currently under discussion in S2) Home Environment+ Local Services OSAGateway HomeCSCF Home Network Local Services SIP OSAGateway servingCSCF serving Network

16. Functions supported by OSA (1) - Framework • Framework • Authentication functions: • Application towards the HE (network) • supports multiple methods, e.g. digital signature • Authorisation functions: • Application is authorised by HE to use certain SCFs • Application is authorised by HE to access a User‘s data • User is authorised by HE to use an Application (= Subscription Check) • Discovery functions • Application get information on authorised Service Capability Features • Establishment of service agreement • Application has to sign the on-line part of a service agreement • Integrity management: Load- and Fault management • Registration of Service Capability Features (interface towards SCFs ! ) • SCF registers itself at the Framework (for later discovery by Applications)

17. Functions supported by OSA (2) - Network • Network • Call- and Session management functions: • Various call- (CS) and data session (GPRS) related functions like:Redirection, Release, Monitor (for e.g. QoS changes..) collect data from user (e.g. DTMF).. • IP Multimedia handling: • Media Chamnels management: open/close/modify/monitor • Confrernce call control: Reserve/fee resources,Conference management: create/join party/remove party .. • Information transfer (notification functions) • Application may send information to the terminal (to a terminal-application):use of SMS or WAP-Push to send short info to the terminal • notification of an Application that a message is received in the user’s mailbox • Charging and e-commerce: • Various functions to allow charging for applications (pre- and post paid, transaction history, one - stop billing ..)

18. Functions supported by OSA (3) - User Data related • User Data related functions • User Status related functions: • Application can retrieve a users status (reachable, terminal info)or be notified on change of user status (terminal attach/detach) • User Location related functions: • Application can retrieve a users location or be notified on change. • User Profile management: • Application can retrieve/modify a users User Profile data.E.g. a list of services to which the end-user is subscribed, service status (active/inactive), privacy status with regards to network service capabilities (e.g. user location, user interaction) • Terminal Cababilities: • Application can retrieve a users present terminal capabilities. • Home- and visited Network Cababilities: • Application can retrieve a users present network capabilities (ffs.).

19. OSA history and documents • The work on OSA was initiated end 1998 as part of VHEJuly 2000: OSA is split from VHE, separate workitem created • The current OSA specifications are mainly based on the Parlay specification with UMTS specific enhancements. OSA work tries to align with ETSI SPAN and the PARLAY group (originally BT, DGM&S Telecom, Microsoft, Nortel Networks and Siemens) • 3GPP specifications • TS 22.osa OSA stage 1 (new specification, split from 22.121 VHE/OSA) • TS 23.127 VHE/OSA - Functional description, stage 2. This is not part of the OSA workitem but contains OSA relevant parts • TS 29.198 OSA - Application Programming Interface - Part 1 • TR 29.998 OSA - Application Programming Interface - Part 2 (recommended mapping to CAMEL)

20. What are the future plans in OSA ? • OSA is an INTERFACE to network functions. OSA exposes network functionality to applications but in general does not create it ! (However OSA is a good starting point to initiate such work !) OSA To-Do list: • enhancement of notification mechanism (depends on addressing recipient-applications in the terminal) • enhancements to User Profile and Terminal Capability functions • IP Multimedia control functions (depends on development of CSCF) • Functions for support of e-commerce • ... • ... [ here come YOUR requirements to OSA !]

21. Any Questions? Thank you for your attention !