Virtual Home Environment VHE and Open Services Access

  • Slides: 21
Download presentation
Virtual Home Environment (VHE) and Open Services Access (OSA) - an overview Jörg Swetina,

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

Main Aspects of VHE and OSA VHE The Virtual Home Environment (VHE) is a

Main Aspects of VHE and OSA VHE The Virtual Home Environment (VHE) is a concept for n a Personal Service Environment (PSE) ü n PSE portability across network boundaries and between terminals. ü n supports services personalisation, multiple user profiles 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, MEx. E, SAT, OSA The Open Services Acess (OSA) is a toolkit within VHE that n enables service providers to make use of network functionality ü n offers an open standardised OO interface (API) to applications ü ü ü 2 call (session) control, management of conferences, location information Application authentication/authorisation, Discovery of service capabilties User Status (Profile, Terminal), Call Control. . . Extensible, Object. Oriented (specified in IDL), Implementation-independent 3/8/2021

Contents n The VHE concept n Goals of VHE n Roles within VHE n

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

The VHE concept - Goals £ Users are consistently presented with the same personalised

The VHE concept - Goals £ Users are consistently presented with the 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. MEx. E, OSA) 4 3/8/2021

Roles in the Virtual Home Environment (I) Value Added Service Provider: offers services directly

Roles in the Virtual Home Environment (I) Value Added Service Provider: offers services directly to the user. Services not part of HE. (But HE may support discovery and access of local services) USER Personal Service Environment Value Added Service Provider User Profile enables a user to manage services according to different situations/needs e. g. at home or at work Personal Service Environment: = entirety of services and personalisation information of a User, managed by HE Provided and controlled by Home Environment Contains 1: N General User Preferences and Subscribed Service Profile, i. e. Specific Service Preferences User Profile N: N Contains 1: N Service HE Value Added Service Provider Services, manged by HE mobility of the service and service personalisation The set of services from the Users point of view (storage / recovery) supported by HE 5 Commercial relationship with the user: the Home Environment provides and controls services to the user in a consistent manner 3/8/2021 Commercial relationship with Home Environment: the HE Value Added Service Provider offers services to the user, may use facilities of PSE

Roles in the Virtual Home Environment (II) n the user’s Home Environment (HE) n

Roles in the Virtual Home Environment (II) n the user’s Home Environment (HE) n n n 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 n a Home Environment Value Added Service Provider (HE-VASP) n n 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 n Services in the user‘s Home Environment n n may access network capabilities (OSA) or run in “operator’s Domain” on terminals (MEx. E) may save personalisation data in a - HE managed - User Profile. n 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. . . n access to and modification of the User Profile is - safely - controlled and maintained by HE n multiple User Profiles group personalisation data according different communication needs n 6 3/8/2021

Toolsets for the realisation of VHE HE OSA VASPs Services VASP non HE Download

Toolsets for the realisation of VHE HE OSA VASPs Services VASP non HE Download Applications and transport of user data HE VASP OSA MEx. E Services Transport of user data (WAP, WWW, FTP. . . ) API SAT Services HE SAT Server Synchronise User Profile OSA GW non standardised interfaces CAMEL ? ? ? e. g. SAT or Internet Services MEx. E Environment CSE 7 3/8/2021

What remains to be done in VHE ? VHE To-Do list: n clear definition

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

n The VHE concept n Goals of VHE n Roles within VHE n Toolsets

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

The OSA toolkit - Goals £ Define a HE controlled access mechanism that enables

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 vendorspecific interfaces. £ Secure, Scalable, Extensible 10 3/8/2021

Driving Forces behind OSA n 3 rd party service providers n n n simple

Driving Forces behind OSA n 3 rd party service providers n n n simple access to Telco-network functionality service provision independent from type of Network allows addressing specific customer segments n Regulator n n enable open, non-discriminatory secure access to network functionality improvement of competition n Network Operator n n n 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) n Supplier n n n 11 new products new business opportunities prerequisite to be compliant with UMTS standard 3/8/2021

Applications executing on an Application Server communicate via OSA API with framework and service

Applications executing on an Application Server communicate via OSA API with framework and service capability servers OSA principles Application server Application discovery OSA interface Open Services Access Interface class framework User Location Call control Service capability server(s) HLR The Framework cares for Authentication/Authorisation of Applications. Additionally SC Servers can Register their SC Features 12 CSE WAP Gateway, Push-Proxy Service Capability Servers provide SC Features (=bundle of interface classes) to Applications. SCSs are logical, not physical entities Servers E. g. Location server MEx. E server SAT server Different kind of network entities / servers realise the functions physically, which are offered by SC Servers through their SC Features 3/8/2021

OSA architectural considerations (I) Relation between SCSs and physical entities Option 1: SCSs and

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 13 Option 3: Hybrid model (combination of 1 and 2) 3/8/2021

OSA architectural considerations (II) the Application‘s view Vo. IP PSTN/ PLMN CSCF OSA API

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

OSA architectural considerations (III) Home- vs. Local IM services support (currently under discussion in

OSA architectural considerations (III) Home- vs. Local IM services support (currently under discussion in S 2) Home Environment + Local Services OSA Gateway Home CSCF Home Network Local Services OSA Gateway SIP serving CSCF serving Network 15 3/8/2021

Functions supported by OSA (1) - Framework n Authentication functions: n n n Authorisation

Functions supported by OSA (1) - Framework n Authentication functions: n n n Authorisation functions: n n Application towards the HE (network) supports multiple methods, e. g. digital signature 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 n Application get information on authorised Service Capability Features Establishment of service agreement n Application has to sign the on-line part of a service agreement n Integrity management: Load- and Fault management n Registration of Service Capability Features (interface towards SCFs ! ) n n 16 SCF registers itself at the Framework (for later discovery by Applications) 3/8/2021

Functions supported by OSA (2) - Network n Call- and Session management functions: n

Functions supported by OSA (2) - Network n Call- and Session management functions: n n IP Multimedia handling: n n n Various call- (CS) and data session (GPRS) related functions like: Redirection, Release, Monitor (for e. g. Qo. S changes. . ) collect data from user (e. g. DTMF). . 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 n notification of an Application that a message is received in the user’s mailbox n n Charging and e-commerce: n 17 Various functions to allow charging for applications (pre- and post paid, transaction history, one - stop billing. . ) 3/8/2021

Functions supported by OSA (3) - User Data related n User Data related functions

Functions supported by OSA (3) - User Data related n User Data related functions n User Status related functions: n n User Location related functions: n n Application can retrieve a users present terminal capabilities. Home- and visited Network Cababilities: n 18 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: n n Application can retrieve a users location or be notified on change. User Profile management: n n Application can retrieve a users status (reachable, terminal info) or be notified on change of user status (terminal attach/detach) Application can retrieve a users present network capabilities (ffs. ). 3/8/2021

OSA history and documents n The work on OSA was initiated end 1998 as

OSA history and documents n The work on OSA was initiated end 1998 as part of VHE July 2000: OSA is split from VHE, separate workitem created n 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) n 3 GPP 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 n TS 29. 198 OSA - Application Programming Interface - Part 1 n TR 29. 998 OSA - Application Programming Interface - Part 2 (recommended mapping to CAMEL) n n 19 3/8/2021

What are the future plans in OSA ? n OSA is an INTERFACE to

What are the future plans in OSA ? n 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: n enhancement of notification mechanism (depends on addressing recipient-applications in the terminal) n enhancements to User Profile and Terminal Capability functions n IP Multimedia control functions (depends on development of CSCF) n Functions for support of e-commerce n . . . n. . . [ here come YOUR requirements to OSA !] 20 3/8/2021

Any Questions? Thank you for your attention ! 21 3/8/2021

Any Questions? Thank you for your attention ! 21 3/8/2021