Wireless Future - Telenor

More documents

Recommendations

Info

Figure 6 SCSs and network functional entities implemented in the same physical entities. From [2] Figure 7 Hybrid implementation. From [2] 96 SCS SCS SCS HLR CSE ---- OSA API SCS SCS “Gateway” HLR CSE ---- OSA API Nonstandardised Interfaces Different SCSs may be implemented on one or more physical entities, separate from the physical network entities. Figure 5 shows one SCS connecting different non-standardised network interfaces. Different SCSs can also use one ‘Gateway’ for each physical network entity. The OSA SCSs can also be implemented in the physical network entity itself, as shown in Figure 6. The possibility to have more than one SCS naturally renders the option of a hybrid solution with some SCSs implemented in the physical network entity and some SCSs in separate physical entities. This is shown in Figure 7. Network operators wanting to offer OSA SCSs will probably implement the last solution shown. The reason for this is the need to use existing non-standardised interfaces already in the network and the need to maintain old services deployed in the network. They can then make or buy an SCS that can use the old interface or buy an upgrade from the infrastructure provider if or when upgrades are available. When expanding the network with new components network operators will in the future be able to buy components including SCSs. Some infrastructure providers will provide network entities containing SCSs, others will provide the SCSs as separate entities which open the market for third part SCSs. Third part SCSs will also be available against today’s non-standardised interfaces. 2.4 Use of Open APIs The provisioning of OSA, Parlay and possibly other open APIs will help network operators to rapidly develop and deploy new services that integrate functionality from several network resources, and this alone will motivate the introduction of OSA. Once the network operator implements OSA or equivalent APIs, the use of the SCSs can be sold to third party operators. Before an external service provider is allowed to access a network operator’s SCSs some sort of agreement is needed. The standard is a Service Level Agreement (SLA), normally a comprehensive contract. The SLA gives a detailed description of all aspects of the deal, such as the extent of the contract, the responsibilities of the network operator and the service provider and actions to be taken if one of the parties does not keep their part of the deal. Once the SLA is signed the service provider can start using the SCSs agreed on. Although the SLA is signed, both on-line authentication with digital signatures and on-line authorisation for use of the SCSs is needed. There are predictions of rapid growth in the number of applications once the 3G mobile networks are available. Network operators will not be able to provide all these applications themselves. The applications provided may fall into four groups: • Applications the network operators provide themselves. The reasons for providing some applications themselves range from being the most cost-efficient, to applications being so critical they have to provide them themselves. • Applications the network operator needs to offer in their network, but chooses to let an external service provider run. These applications range from compulsory services the network operators are required to provide, to applications that are complementary to their own and able to generate extra traffic. • Applications that a third party wants to run, with no other benefit for the network operator than the generated traffic. • Applications that use SCSs from more than one network operator. The largest growth will probably be in contextbased services, and then especially in services using location information. Telektronikk 1.2001
2.5 The <strong>Future</strong> of OSA First some extensions and improvements already agreed on by the groups in 3GPP that are standardising OSA are described and then possible future enhancements are discussed. The charging functionality of OSA will in the future allow the application to charge end-users’ account for services provided. Both soft (e.g. download of music, software, video) and hard (e.g. CDs, books, DVDs) goods may be invoiced. The responsibility for the subscriber accounts can be assigned to the network operator or elsewhere. The network operator may also choose to be partially responsible for the account and send out invoices for traffic and subscription costs and leave the rest to a third party. Regardless of who handles the billing the means to divide the charging of a call controlled by an application between the network operator and the application provider is required. Multi-Media Channel Control will be added. This will allow applications to control individual channels in IP Multimedia calls. The Multi- Media Channel Control functionality will be equivalent to the Call Control interfaces. <strong>Future</strong> enhancements of the OSA API could include the following: • Logging functionality is needed by the applications for charging and statistics. It can also be used for fraud detection. • Speech synthesis support would be helpful in many applications such as reading of faxes and e-mails. • Speech recognition support would be helpful in many applications such as automated directory inquiries. • E-mail and fax support, with speech generation and recognition. • Unified Messaging has been a hot topic for some time. Support for this would be useful. 3 Changes in the Business Model So far we have seen little discussion around the topic of business models for UMTS but in opening up for external service providers this will also require a new model for how business is done. Figure 8 shows a simplified view of the old business model. In both cases shown the telecom operator is responsible for delivering the service to the customer. In the model to the right a service provider is involved in provisioning the ser- Telektronikk 1.2001 vice, but the operator is still the one who delivers the service to the customer. In the next figure a possible new business model that fits the new way of providing services is shown. Figure 9 shows an ideal layered model where each layer only has relations to the nearest layer above or beneath itself. This is of course an idealistic model and the reality is far from that simple. An example of this is that it is likely that Service Providers also will provide services directly to the Consumer without the involvement of a Service Distributor. Other cross relations and other roles not mentioned here are of course also possible. 3.1 Network Operator The Network Operator in this model provides the transport and access networks and is responsible for the operation, administration and maintenance of these networks. The Network Operator is also responsible for the different network resources; this includes the operation of the open interfaces, used by both internal and external service providers for the support of their services. This provisioning of open interfaces is the service provided by the Network Operator to the Service provider in the model in Figure 9. 3.2 Service Provider The Service Provider is responsible for the operation, administration and maintenance of services and to provide these services to a Service Distributor. He is also responsible for maintaining the customer data used to configure the service for a particular user. 3.3 Service Creator The Service Creator is the one who implements a service. This role can be filled by the Service Provider but can also be done by a company external to the Service Provider that in this case hosts or buys the service from the Service Creator. The Service Creator would have no other relations than to the Service Provider Consumer Consumer Service Delivery Service Billing Service Delivery Value Added Provider Operator Operator Billing Billing Figure 8 The old business model. From [10] 97
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 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 112 and 113: 110 Box 1 - The Open Service Archit
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

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?