Wireless Future - Telenor

More documents

Recommendations

Info

110 Box 1 – The Open Service Architecture (OSA) 3GPP has standardized an Open Service Architecture. This architecture defines an open API for design, implementation, control and execution and application provided by network operators and third party providers. Applications can be network/server centric or terminal centric. Terminal centric applications reside in the Mobile Station. Network/server centric applications are running outside the core network and make use of service capability features offered through the OSA API. (Note that applications may belong to the network operator domain although running outside the core network. Being outside the core network means that the applications are executed in Application Servers that are physically separated from the core network entities.) discovery Open Service Access framework User Location Overview of the Open Service Architecture Call Control OSA internal API HLR CSE WGW WPP The SCSs provide their features to applications in Service Capability Features (SCFs). For Rel’99 the following Network SCFs are defined: Call Control, Data Session, User Location, User Status, Terminal Capabilities and Message Transfer. Note that call control only supports one-to-one calls and the applications cannot initiate a call. Administering the VT Read usage statistics Read mailbox uses extends Defining/deleting a device Registering/ deregistering a device Figure 6 Use case diagram for administering the Virtual Terminal The Open Service Architecture (OSA) defines an architecture that enables operator and third party applications to make use of network functionality through an open standardised API (the OSA API). OSA thus provides the glue between applications and service capabilities provided by the network, and applications become independent of the underlying network technology. The applications constitute the top level of the Open Service Architecture (OSA). This level is connected to the Service Capability Servers (SCSs) via the OSA API. The SCSs map the OSA API into the underlying telecom specific protocols (e.g. MAP, CAP, etc.), and are therefore hiding the network complexity from the applications. Service capability server(s) Servers E.g. Location server MExE server SAT server Application server Application OSA API Interface class All interfaces are specified in OMG IDL, which makes OSA API independent of programming language, platform and Operating System. It is up to the implementers to map the OSA API to other proprietary protocols like H.323 and SIP. Current Release of OSA is Release 4 and the specification and IDL files are available for free download at www.3gpp.org. Accessing profile Authentication & access control 4.5 Administering the Virtual Terminal This article identifies five extensions of this use case: accessing profile (which allows the user to read and make changes to his profile), defining/ deleting a device (where the user specifies which devices to be constituents of the Virtual Terminal, i.e. which devices are known by the Virtual Terminal and hence can be used for future sessions), registering/deregistering a device (where the user can specify for any given time which specific device to be registered at), reading mailbox and reading usage statistics. Admission to the Virtual Terminal should be restricted to the user only. This means that all of the five use cases extending Administering the Virtual Terminal mentioned above involve a use case authentication and access control. These use cases are shown in Figure 6. Telektronikk 1.2001
5 How should the System Architecture be? In order to realise the Virtual Terminal concept as described in the aforementioned visions and demands a terminal management and co-ordination function called Virtual Terminal is needed. In short, such a function should have the following capabilities: It should continuously maintain, monitor and update the configuration of the Virtual Terminal, i.e. it knows exactly what devices are present and active in the Virtual Terminal. It should also be able to multiply and deliver streams from applications to respective devices and to unify and deliver streams from devices to respective applications. There are three alternatives concerning the location of this Virtual Terminal: • On a user’s mobile device; • On a user-owned stationary device such as a PC; • On a server somewhere in the network, owned by a service provider. The first alternative has the advantage that it is closer to the devices and hence easier to implement. The major drawback lays in the fact that the mobile device might lose contact with the system and it is more exposed to damage or theft. The second alternative is not convenient since it requires the user to have an expensive stationary device, which is not always the case. Finally, although most challenging to realize, the last alternative proves to be the best since it is the most flexible. It does not require that the user owns an expensive terminal, and roaming is provided to allow the user to move away from his home domain while keeping in touch with his Virtual Terminal. This conclusion regarding location is in agreement with other research projects’ conclusions [6]. Figure 7 shows the proposed system architecture of the Virtual Terminal. Other applications are only aware of the Virtual Terminal and not of the user’s many devices. Applications will deliver services to the Virtual Terminal, which again has the responsibility to ensure that the delivery to the user is done via the most appropriate device. From a technological viewpoint, the Virtual Terminal object could reside on a standard server that is connected to an IP-based network as shown in Figure 8. All the networks are connected together by gateways. Telektronikk 1.2001 6 How could the Virtual Terminal be Implemented? In this section we will study successively the five main use cases and discuss the possible implementation alternatives. 6.1 Initiating Services By service is meant both communication and computing services. The user has at his disposal a set of devices and can initiate services from any of them. For the use cases Initiating data service and Initiating directly communication service no additional functionality than the existing ones on the device is required. The user can just select the device he wants to and initiate service directly from there without going through the Virtual Terminal. However, if he later on wants to swap to another device the initiation must have been done through the Virtual Terminal in the first place or this will not be possible. Further, for the use cases Initiating communication service via address book and for a group, additional functionality is required if a common address book for all devices is wanted. User X:User 1:Device 2:Device 3:Device ISUP PSTN/ISDN Gateway The Virtual Terminal ISUP Gateway Gateway Mobile Network Figure 7 The Virtual Terminal Architecture Application Virtual Terminal Telecom system Figure 8 Physical network connection of the Virtual Terminal SIP/H323 IP-based Network X:Virtual Terminal 111
Page 2 and 3:
Telektronikk Volume 97 No. 1 - 2001
Page 4 and 5:
Per Hjalmar Lehne (42) obtained his
Page 6 and 7:
Stein Svaet (41) is Senior Research
Page 8 and 9:
Pbit/day 6 150 125 100 75 50 25 0 F
Page 10 and 11:
8 Video communication as a utility
Page 12 and 13:
10 The idea of reconfigurable mobil
Page 14 and 15:
12 Switched lobe Dynamically phased
Page 16 and 17:
Figure 10 The All IP vision Figure
Page 18 and 19:
16 The IP world has some problems t
Page 20 and 21:
18 Abbreviations and acronyms less
Page 22 and 23:
Jorge Pereira (40) obtained his Eng
Page 24 and 25:
(Millions) Figure 1 Exponential gro
Page 26 and 27:
24 Defining Generation based upon D
Page 28 and 29:
Multi-mode Terminal by Software Rad
Page 30 and 31:
distribution layer possible return
Page 32 and 33:
30 A Co-Ordinated Approach to 4G As
Page 34 and 35:
Figure 2 Applications will grow fas
Page 36 and 37:
Figure 5 Evolution from multi-mode
Page 38 and 39:
Operator/Provider download librarie
Page 40 and 41:
Radio network subsystem - service c
Page 42 and 43:
Dr. Techn. Jørgen Bach Andersen (6
Page 44 and 45:
Figure 3 Two arrays with M and N el
Page 46 and 47:
Figure 5 Cumulative probability dis
Page 48 and 49:
Figure 8 As in Figure 5, but with F
Page 50 and 51:
48 Conclusion The challenge of prov
Page 52 and 53:
50 models are described simply by a
Page 54 and 55:
52 ping intervals or “quantizatio
Page 56 and 57:
Figure 3 ASE as a function of the a
Page 58 and 59:
56 7 Conclusion and Further Researc
Page 60 and 61:
Dave Wisely (39) graduated in 1982
Page 62 and 63: Figure 2 Business case study Figure
Page 64 and 65: Figure 6 BRAIN QoS architecture 62
Page 66 and 67: 64 4 BRAIN homepage. (2001, March 6
Page 68 and 69: Figure 2 The Bluetooth protocol sta
Page 70 and 71: Figure 5 A Bluetooth radio module i
Page 72 and 73: 70 • Instant postcard: A Bluetoot
Page 74 and 75: 72 work visions come true, it is ne
Page 76 and 77: Table 1 Allocated HiperLAN bands (i
Page 78 and 79: Figure 4 Basic MAC frame structure
Page 80 and 81: 78 Preamble BCH FCH ACHs Preamble S
Page 82 and 83: throughput bit/s 80 3 2.5 2 1.5 1 0
Page 84 and 85: 82 5 References 1 CEPT. ERC Decisio
Page 86 and 87: 84 IETF Internet Engineering Task F
Page 88 and 89: Figure 2-3 Mobile IPv6 architecture
Page 90 and 91: 88 domain, it attaches to a new lea
Page 92 and 93: 90 Domain GFA/MAP Figure 3-3 Archit
Page 94 and 95: Geir Gylterud (35) is Research Scie
Page 96 and 97: 94 Framework Resource Resource Int
Page 98 and 99: Figure 6 SCSs and network functiona
Page 100 and 101: Figure 9 The new business model. Fr
Page 102 and 103: 100 A strong consortium backs up th
Page 104 and 105: 102 Music Company Figure 3 Service
Page 106 and 107: Figure 4 OSA architecture service c
Page 108 and 109: Do van Thanh (43) obtained his MSc
Page 110 and 111: Figure 2 The first use case diagram
Page 114 and 115: 112 X:User 1:Device 2:Device 3:Devi
Page 116 and 117: Figure 10 Initiating call from PSTN
Page 118 and 119: Figure 13 Splitting the incoming st
Page 120 and 121: Figure 17 A set of communication de
Page 122 and 123: 120 Box 3 continued Session Descrip
Page 124 and 125: Figure 21 A laptop and peripheral d
Page 126 and 127: 124 Box 4 - Bluetooth Bluetooth is
Page 128 and 129: 126 6 The ICEBERG project. (2001, M
Page 130 and 131: 128 new door towards the upcoming f
Page 132 and 133: ? Figure 1 The Mobile Service Platf
Page 134 and 135: Figure 2 Needs and Related Services
Page 136 and 137: 134 Telektronikk 1.2001
Page 138 and 139: 136 Telektronikk 1.2001
Page 140 and 141: Anne Lise Lillebø (52) is Adviser
Page 142 and 143: 140 with other SDOs (Standards Deve
Page 144 and 145: 142 Box 2 - ETNO Declaration We, th
Page 146 and 147: Arve Meisinset (52) is Senior Resea
Page 148 and 149: 146 In ITU-T we have seen needs to
Page 150 and 151: 148 Each viewpoint constitutes a se
Page 152 and 153: Figure 2 UML class diagrams for tra
Page 154 and 155: 152 The functionality describing th
Page 156 and 157: 154 9 Potter, B et al. An introduct
show all

Wireless Future - Telenor

Create successful ePaper yourself

Delete template?

Save as template?