v irtual h ome e nvironment ( vhe ) and o pen s ervices a ccess ( osa ) - an overview
Post on 31-Dec-2015
38 Views
Preview:
DESCRIPTION
TRANSCRIPT
04/19/23Information and Communication Networks_1Dr. Jörg Swetina
Virtual Home Environment (VHE)and
Open Services Access (OSA)- an overview
Jörg Swetina, SIEMENS AGTel: +43 51707 21422
mobile: +43 676 4912429mail: joerg.swetina@siemens.at
3GPP TSG-T2 #10Galway, IRELANDAugust 28th - September 1th 2000
T2-000469
04/19/23Information and Communication Networks_2Dr. Jörg Swetina
Main Aspects of VHE and OSAMain Aspects of VHE and OSA
VHEThe 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
OSAThe 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
04/19/23Information and Communication Networks_3Dr. Jörg Swetina
ContentsContents
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
04/19/23Information and Communication Networks_4Dr. Jörg Swetina
The VHE concept - GoalsThe 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)
04/19/23Information and Communication Networks_5Dr. Jörg Swetina
Roles in the Virtual Home Environment (I)Roles in the Virtual Home Environment (I)
General User Preferences and Subscribed Service
USER
PersonalService
Environment
HomeEnvironment
Provided andcontrolled by
UserProfile
Contains1:N
Contains1:N
Value AddedService Provider
HE Value AddedService Provider
N:N
The set of services from the Users point of view
Service Profile, i.e. Specific ServicePreferences
Service
Commercial relationshipwith the user:the Home Environment provides and controlsservices to the userin a consistent manner
Personal ServiceEnvironment: =entirety of services andpersonalisation informationof a User, managed by HE
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
Commercial relationshipwith Home Environment:the HE Value AddedService Provider offersservices to the user, mayuse facilities of PSE
Value Added ServiceProvider: offers servicesdirectly to the user.Services not part of HE.(But HE may support discovery and accessof local services)
04/19/23Information and Communication Networks_6Dr. Jörg Swetina
Roles in the Virtual Home Environment (II)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
04/19/23Information and Communication Networks_7Dr. Jörg Swetina
HE VASP
Toolsets for the realisation of VHEToolsets for the realisation of VHE
CSE
OSAServices
OSA GW
CAMELServices
SATServices
MExEServices
??? e.g. SAT or MExE Environment
SAT Server
OSA API
HE VASPVASP Download Applicationsand transport of user data
Synchronise User Profile
Internet
HE
HEVASPs
Transport of user data(WAP, WWW, FTP...)
non HE
non standardised interfaces
04/19/23Information and Communication Networks_8Dr. Jörg Swetina
What remains to be done in VHE ?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
04/19/23Information and Communication Networks_9Dr. Jörg Swetina
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
04/19/23Information and Communication Networks_10Dr. Jörg Swetina
The OSA toolkit - GoalsThe 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
04/19/23Information and Communication Networks_11Dr. Jörg Swetina
Driving Forces behind OSADriving 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
04/19/23Information and Communication Networks_12Dr. Jörg Swetina
OSA principlesOSA principles
framework User Location Call control
HLR CSE WAP
Gateway,Push-Proxy
Servers
E.g. Location server MExE server SAT server
Service capability server(s)
Interfaceclass
OSA interface
OpenServicesAccess
discovery Application
Applicationserver
Applications executing onan Application Servercommunicate via OSA APIwith framework andservice capability servers
The Framework cares for Authentication/Authorisationof Applications.Additionally SC Servers can Register their SC Features
Service Capability Serversprovide SC Features(=bundle of interface classes)to Applications. SCSs arelogical, not physical entities
Different kind of network entities / servers realise the functions physically, whichare offered by SC Serversthrough their SC Features
04/19/23Information and Communication Networks_13Dr. Jörg Swetina
OSA architectural considerations (I)Relation between SCSs and physical entitiesOSA architectural considerations (I)Relation between SCSs and physical entities
SCS ‘Gateway’
OSA Interface
Non-standardisedInterfaces
CSE ….HLR
SCS SCS
SCSOSA Interface
CSE ….HLR
SCS SCS
‘Gateway’
OSA Interface
Non-standardisedInterfaces
CSE ….HLR
SCS SCS
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)
SCS ‘Gateway’
OSA Interface
Non-standardisedInterfaces
CSE ….HLR
04/19/23Information and Communication Networks_14Dr. Jörg Swetina
OSA architectural considerations (II)the Application‘s viewOSA architectural considerations (II)the Application‘s view
Application system
Applicationusing
networkservices Data
base
Enterprise Domain
OSA API
SCP
HLR
Switch
VoIP
OSAGateway
Telecom Network Domain
PSTN/PLMN
CSCF
e.g. CORBA
04/19/23Information and Communication Networks_15Dr. Jörg Swetina
OSA architectural considerations (III)Home- vs. Local IM services support (currently under discussion in S2)
OSA architectural considerations (III)Home- vs. Local IM services support (currently under discussion in S2)
Home Network
HomeCSCF
OSAGateway
Home Environment+ Local Services
serving Network
servingCSCF
OSAGateway
Local Services
SIP
04/19/23Information and Communication Networks_16Dr. Jörg Swetina
Functions supported by OSA (1) - FrameworkFunctions 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)
04/19/23Information and Communication Networks_17Dr. Jörg Swetina
Functions supported by OSA (2) - NetworkFunctions 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 ..)
04/19/23Information and Communication Networks_18Dr. Jörg Swetina
Functions supported by OSA (3) - User Data relatedFunctions 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.).
04/19/23Information and Communication Networks_19Dr. Jörg Swetina
OSA history and documentsOSA 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)
04/19/23Information and Communication Networks_20Dr. Jörg Swetina
What are the future plans in OSA ?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 !]
04/19/23Information and Communication Networks_21Dr. Jörg Swetina
Any Questions?
Thank you for your attention !
top related