Wireless Future - Telenor

More documents

Recommendations

Info

120 Box 3 continued Session Description Protocol (SDP) The Session Description Protocol, or SDP, is a protocol for describing audio, video and multimedia sessions. SIP, MGCP (Media Gateway Control Protocol), SAP (Session Announcement Protocol) and RTSP (Real-Time Streaming Protocol) all use SDP. Relationship Between SIP and H.323 Both SIP and H.323 define mechanisms for call routing, call signalling, capabilities exchange, media control, and supplementary Figure 19 Changing device offline Figure 20 Redirecting the input and output streams 6.3.3.1 Changing Device We assume that sometimes the user will only use one device for a service, for example his cellular phone. If the user recognises a more appropriate device, for example his desktop telephone when he enters his office, he should be able to switch to this device even during an ongoing session. He must then in some way tell his Virtual Terminal that he wants to change, and the Virtual Terminal will redirect the input and output streams to this new device. 1:Device X:Virtual Terminal 1:Device X:Virtual Terminal X:User A X:User A 2:Device 3:Device services. SIP is a new protocol that promises scalability, flexibility and ease of implementation when building complex systems. H.323 is an established protocol that has been widely used because of its manageability, reliability and interoperability with PSTN. There is a general consensus among standards organizations, companies and technology experts that standardized procedures need to be specified to allow seamless interworking between the two protocols. Bodies such as TIPHON (ETSI), aHIT (IMTC) and IETF are working to address this topic. 1:Device X:Virtual Terminal 1:Device X:Virtual Terminal X:User X:User The changing of the active device during a session is shown in Figure 18, where the user has an ongoing session delivered to device 1, then tells the Virtual Terminal to change active device to device 2, and then finally the Virtual Terminal delivers the service to device 2 where the user can continue his session. The communication between the user and the Virtual Terminal will always be via the active device. This changing of devices should be very easy to use for the user and preferably seamless with respect to the running applications. 2:Device 1:Device X:Virtual Terminal X:User B C 3:Device 1:Device X:Virtual Terminal X:User B C 2:Device 2:Device 2:Device 2:Device 3:Device Telektronikk 1.2001
Even when the user does not have an active session going on, he might still be registered at a device. This is specified so that any incoming service requests will be delivered to this device. If the user wants to change which device to receive a possible service request on, he may communicate this to the Virtual Terminal, which will consider the new device as where to reach the user. This situation is shown in Figure 19. It should also be possible for the Virtual Terminal to automatically change which devices to be registered at according to the user profile and depending on for example time of day and the location of the user. In this case the user will not have to tell specifically which device to use as long as he has already configured his profile correctly. 6.3.3.2 Changing the Input and Output If the user wants to change only some parts of the input or output streams, the Virtual Terminal should allow him to do so. These changes will be relevant to the user in cases where he arrives at places where more appropriate devices are located or if his services are changing and hence require different output or input quality. The user should be able to tell the Virtual Terminal through his active device which devices he wants services to be delivered to at any time as shown in Figure 20. He should be able to switch back and forth as many times as he likes and to any available devices he has access to. The Virtual Terminal should always know what type of devices the user wants to use. The user can either specify this whenever he switches to a new device, or if it is a previously known device, this information can be contained in the profile within the Virtual Terminal so that it already knows what type it is, i.e. voice, video or data, and whether it is offering output or input capabilities, etc. 6.3.4 Adding and Releasing new Devices Since each device often has a limited user interface, the combination of several devices will offer the user better user interfaces and hence better services. During a service session a user may want to add one or more elementary devices with just input or output functionality, e.g. a big screen display, speakers, microphone etc. or more smart devices like PC, smart phone, etc. to the session. We may consider the cases where the new device is trusted or known by the Virtual Terminal and where it is not. 6.3.4.1 Adding known Devices to a Session In the case where the new devices are trusted or known to the Virtual Terminal, e.g. devices at Telektronikk 1.2001 the user’s home or office, the Virtual Terminal already knows which services those devices can offer and how they can work in combination with the main active device. One can include those devices in the user service profile on the Virtual Terminal in advance, and with a few simple key presses on the active device one can request the Virtual Terminal to add or release one or several of these devices to or from the service. This requires that the new devices have network connection and the Virtual Terminal is responsible for the rerouting and if required, for the splitting of the stream. It means that the stream should go via the Virtual Terminal. In the cases when new devices do not have network connection, Bluetooth may be used to add new devices to the service, but then the Virtual Terminal does not need to be involved in the adding process. 6.3.4.2 Adding unknown Devices to a Session If the new devices are unknown, the establishment of a multi-device session is more complicated. If a new device is unknown to the Virtual Terminal, the IP address and the identity of the device as well as information about which kind of services the device can offer must be found out. This can either be done manually by the user or automatically by the active device. To do this manually is often not preferred since it requires user involvement. Another problem is that unknown devices are also un-trusted by each other, so some kind of mutual authentication and access control has to be performed. With an automatic process one is faced with general problems like: • Automatic discovery of devices. Both networked and not networked devices; • Ability of device to announce its presence to the network; • Ability to describe its capability as well as query/understand the capabilities of other devices; • Seamless interoperability with each other and self-configuration without administrative intervention; • Security issues. Some new technologies like Universal Plug and Play [13], Salutation [14], Bluetooth [2], Jini, etc. [15,16,17] may be used to solve these problems. When the identity and other characteristics of the new devices are known, it is possible to add them to the ongoing service session. 121
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 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 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?