idnits 2.17.1 draft-bernardos-dmm-sfc-mobility-04.txt: -(206): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(212): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(213): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(219): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(221): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(223): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(225): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(228): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(229): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(232): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(234): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(236): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(238): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 13 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (21 March 2022) is 759 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-06) exists of draft-bernardos-sfc-distributed-control-05 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SFC WG CJ. Bernardos 3 Internet-Draft UC3M 4 Intended status: Experimental A. Mourad 5 Expires: 22 September 2022 InterDigital 6 21 March 2022 8 SFC function mobility with Mobile IPv6 9 draft-bernardos-dmm-sfc-mobility-04 11 Abstract 13 Service function chaining (SFC) allows the instantiation of an 14 ordered set of service functions and subsequent "steering" of traffic 15 through them. In order to set up and maintain SFC instances, a 16 control plane is required, which typically is centralized. In 17 certain environments, such as fog computing ones, such centralized 18 control might not be feasible, calling for distributed SFC control 19 solutions. This document specifies Mobile IPv6 extensions to enable 20 function migration in SFC. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on 22 September 2022. 39 Copyright Notice 41 Copyright (c) 2022 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Revised BSD License text as 50 described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Revised BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Function mobility signaling extending Mobile IPv6 . . . . . . 5 58 4. Mobile IPv6 extensions for SFC function mobility . . . . . . 6 59 4.1. Service Path Update . . . . . . . . . . . . . . . . . . . 6 60 4.2. Service Path Acknowledgement . . . . . . . . . . . . . . 8 61 4.3. New Mobility options . . . . . . . . . . . . . . . . . . 9 62 4.3.1. Network Service ID . . . . . . . . . . . . . . . . . 9 63 4.3.2. SFC node . . . . . . . . . . . . . . . . . . . . . . 10 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 66 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 69 8.2. Informative References . . . . . . . . . . . . . . . . . 12 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 72 1. Introduction 74 Virtualization of functions provides operators with tools to deploy 75 new services much faster, as compared to the traditional use of 76 monolithic and tightly integrated dedicated machinery. As a natural 77 next step, mobile network operators need to re-think how to evolve 78 their existing network infrastructures and how to deploy new ones to 79 address the challenges posed by the increasing customers' demands, as 80 well as by the huge competition among operators. All these changes 81 are triggering the need for a modification in the way operators and 82 infrastructure providers operate their networks, as they need to 83 significantly reduce the costs incurred in deploying a new service 84 and operating it. Some of the mechanisms that are being considered 85 and already adopted by operators include: sharing of network 86 infrastructure to reduce costs, virtualization of core servers 87 running in data centers as a way of supporting their load-aware 88 elastic dimensioning, and dynamic energy policies to reduce the 89 monthly electricity bill. However, this has proved to be tough to 90 put in practice, and not enough. Indeed, it is not easy to deploy 91 new mechanisms in a running operational network due to the high 92 dependency on proprietary (and sometime obscure) protocols and 93 interfaces, which are complex to manage and often require configuring 94 multiple devices in a decentralized way. 96 Service Functions are widely deployed and essential in many networks. 97 These Service Functions provide a range of features such as security, 98 WAN acceleration, and server load balancing. Service Functions may 99 be instantiated at different points in the network infrastructure 100 such as data center, the WAN, the RAN, and even on mobile nodes. 102 Service functions (SFs), also referred to as VNFs, or just functions, 103 are hosted on compute, storage and networking resources. The hosting 104 environment of a function is called Service Function Provider or 105 NFVI-PoP (using ETSI NFV terminology). 107 Services are typically formed as a composition of SFs (VNFs), with 108 each SF providing a specific function of the whole service. Services 109 also referred to as Network Services (NS), according to ETSI 110 terminology. 112 With the arrival of virtualization, the deployment model for service 113 function is evolving to one where the traffic is steered through the 114 functions wherever they are deployed (functions do not need to be 115 deployed in the traffic path anymore). For a given service, the 116 abstracted view of the required service functions and the order in 117 which they are to be applied is called a Service Function Chain 118 (SFC). An SFC is instantiated through selection of specific service 119 function instances on specific network nodes to form a service graph: 120 this is called a Service Function Path (SFP). The service functions 121 may be applied at any layer within the network protocol stack 122 (network layer, transport layer, application layer, etc.). 124 The concept of fog computing has emerged driven by the Internet of 125 Things (IoT) due to the need of handling the data generated from the 126 end-user devices. The term fog is referred to any networked 127 computational resource in the continuum between things and cloud. A 128 fog node may therefore be an infrastructure network node such as an 129 eNodeB or gNodeB, an edge server, a customer premises equipment 130 (CPE), or even a user equipment (UE) terminal node such as a laptop, 131 a smartphone, or a computing unit on-board a vehicle, robot or drone. 133 In fog computing, the functions composing an SFC are hosted on 134 resources that are inherently heterogeneous, volatile and mobile 135 [I-D.bernardos-sfc-fog-ran]. This means that resources might appear 136 and disappear, and the connectivity characteristics between these 137 resources may also change dynamically. These scenarios call for 138 distributed SFC control solutions, where there are SFC pseudo 139 controllers, enabling autonomous SFC self-orchestration capabilities. 140 The concept of SFC pseudo controller (P-CTRL) is described in 141 [I-D.bernardos-sfc-distributed-control], as well different procedures 142 for their discovery and initialization. 144 This document specifies Mobile IPv6 extensions to enable function 145 migration in SFC. 147 2. Terminology 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 151 document are to be interpreted as described in [RFC2119]. 153 The following terms used in this document are defined by the IETF in 154 [RFC7665]: 156 Service Function (SF): a function that is responsible for specific 157 treatment of received packets (e.g., firewall, load balancer). 159 Service Function Chain (SFC): for a given service, the abstracted 160 view of the required service functions and the order in which they 161 are to be applied. This is somehow equivalent to the Network 162 Function Forwarding Graph (NF-FG) at ETSI. 164 Service Function Forwarder (SFF): A service function forwarder is 165 responsible for forwarding traffic to one or more connected 166 service functions according to information carried in the SFC 167 encapsulation, as well as handling traffic coming back from the 168 SF. 170 SFI: SF instance. 172 Service Function Path (SFP): the selection of specific service 173 function instances on specific network nodes to form a service 174 graph through which an SFC is instantiated. 176 The following terms are used in this document: 178 SFC Pseudo Controller (P-CTRL): logical entity 179 [I-D.bernardos-sfc-distributed-control], complementing the SFC 180 controller/orchestrator found in current architectures and 181 deployments. It is service specific, meaning that it is defined 182 and meaningful in the context of a given network service. 183 Compared to existing SFC controllers/orchestrators, which manage 184 multiple SFCs instantiated over a common infrastructure, pseudo 185 controllers are constrained to service specific lifecycle 186 management. 188 SFC Central Controller (C-CTRL): central control plane logical 189 entity in charge of configuring and managing the SFC components 190 [RFC7665]. 192 3. Function mobility signaling extending Mobile IPv6 194 This section describes Mobile IPv6 (MIPv6) extensions to perform 195 function migration/mobility. This is an example of NS lifecycle 196 management operation: the update of the location of a given function. 197 We refer to this as function mobility, though it might involve or not 198 the actual migration of the function. 200 +---------+ +----+ +---------+ +---------+ +----------+ +------+ 201 | node A | | C | | node B | | node D | | 3GPP | | SFC | 202 |P-CTRL F1| | F3 | |P-CTRL F2| |P-CTRL F3| |ctrl plane| |C-CTRL| 203 +--+----+-+ +----+ +--+----+-+ +--+----+-+ +----------+ +------+ 204 | | | | | | | | | 205 | F1@A<->F2@B<->F3@D SFC network service | | 206 | |<-·-·-·-·-·-·-·-·-·>|<-·-·-·-·->| | | 207 | | | | | | | | | 208 | | | Node B moves out of | | 209 | | | the coverage of node D | | 210 | | | | | | | | | 211 | 0. Service specific OAM monitoring | | | 212 |<-·>|<-·-·->|<-·-·-·-·-·>| | | | | 213 |<-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·->| | 214 | | | | | | | | | 215 P-CTRL@A detects D disconnection | | | | 216 and decides to place F3 at node C | | | | 217 | | | | | | | | | 218 | 1a. SPU[NS_ID,(F3,C)] | | | | | 219 |-·-·-·-·-·-·-·-·-·-·-·-·>| | | | | 220 | 1b. SPA[NS_ID] | | | | | 221 |<-·-·-·-·-·-·-·-·-·-·-·-·| | | | | 222 | 1c. SPU[NS_ID,(F3,C),(F2,B),(F1,A)] | | | 223 |-·-·-·-·-·->| | | | | | | 224 | 1d. SPA[NS_ID] | | | | | | 225 |<-·-·-·-·-·-| | | | | | | 226 | | | | | | | | | 227 | 2. Updated F1@A<->F2@B<->F3@C SFC network service | 228 | |<-·-·-·-·-·-·-·-·-·>| | | | | 229 | | |<-·-·-·-·-·>| | | | | 230 | | | | | | | | | 231 | 3a. SPU[NS_ID,(F3,C),(F2,B),(F1,A)] | | 232 |-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·->| 233 | | | | | | | 3b. SPA[NS_ID] | 234 |<-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-| 235 | 3c. SPU[NS_ID,(F3,C)] | | | | | 236 |-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·>| | | 237 | | | | 3d. SPA[NS_ID] | | | 238 |<-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-| 239 | | | | | | | | | 240 Figure 1: SFC mobility signaling 242 We next describe the signaling extensions with an example. For the 243 sake of this example we assume that the function which location is 244 updated is already available at the new target node (if not, it has 245 to be previously migrated using any of the solutions available in the 246 state-of-the-art). The different steps are described next: 248 * (The network service F1--F2--F3 is already instantiated and 249 running. The only SFC P-CTRL active at this point is running at 250 node A, and there is a candidate one at node B.) 252 * UE node B is moving out of the coverage of gNB node D. 254 1. This movement is detected by the active (designated) pseudo 255 controller running at node A, thanks to local (service specific 256 OAM) monitoring. 258 2. The active pseudo controller sends mobility signaling to all 259 affected nodes, in this case node B (it has to update the network 260 service path due to the F3 location update) and node C (as it 261 starts being part of the SFC, hosting F3). The signaling 262 messages are new mobility messages: Service Path Update (SPU) and 263 Service Path Acknowledgement (SPA), which contain: (i) the 264 identifier of the network service (NS_ID), and (ii) the updated 265 elements of the network service path: (ID, updated location). 266 The SPA acknowledges that the procedure has been performed 267 correctly. 269 3. The network service F1--F2--F3 is updated so it now runs at A, B 270 and C. 272 4. Whenever connectivity with nodes D and the centralized SFC 273 controller is back, the pseudo controller also informs about the 274 updated SFC path, sending SPU messages, which are acknowledged 275 with SPA messages. 277 Note that this is an example of NS lifecycle management (function 278 mobility) by a SFC pseudo controller, but that other operations are 279 also possible, such as (non-limiting examples): scaling up/down, 280 scaling in/out, termination, etc. 282 4. Mobile IPv6 extensions for SFC function mobility 284 4.1. Service Path Update 286 The Service Path Update (SPU) message is used by a CTRL to notify 287 nodes in an SFC (e.g., SFF) of an update of the service path. 289 The Service Path Update uses the MH Type value TBD. When this value 290 is indicated in the MH Type field, the format of the Message Data 291 field in the Mobility Header is as follows: 293 0 1 2 3 294 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | Sequence # | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 |A| Reserved | Lifetime | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | | 301 . . 302 . Mobility Options . 303 . . 304 | | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 Sequence # 309 A 16-bit unsigned integer used by the receiving node to sequence 310 Binding Updates and by the sending node to match a returned 311 Service Path Acknowledgement with this Service Path Update. 313 Acknowledge (A) 315 The Acknowledge (A) bit is set by the sending mobile node to 316 request a Service Path Acknowledgement be returned upon receipt of 317 the Service Path Update. 319 Reserved 321 This field is unused for now. The value MUST be initialized to 0 322 by the sender and MUST be ignored by the receiver. 324 Lifetime 326 16-bit unsigned integer. The number of time units remaining 327 before the service path MUST be considered expired. A value of 328 zero indicates that the Service Path MUST be deleted. A value of 329 0xFFFF indicates an infinite lifetime for the Service Path. One 330 time unit is 4 seconds. 332 Mobility Options 333 Variable-length field of such length that the complete Mobility 334 Header is an integer multiple of 8 octets long. This field 335 contains zero or more TLV-encoded mobility options. The receiver 336 MUST ignore and skip any options that it does not understand. 338 The following options are valid in a Service Path Update: 340 - Network Service ID. 342 - SFC node. 344 4.2. Service Path Acknowledgement 346 The Service Path Acknowledgement (SPA) message is used by a CTRL to 347 acknowledge a received SPU. 349 The Service Path Acknowledge uses the MH Type value TBD. When this 350 value is indicated in the MH Type field, the format of the Message 351 Data field in the Mobility Header is as follows: 353 0 1 2 3 354 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | Sequence # | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | Reserved | Lifetime | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | | 361 . . 362 . Mobility Options . 363 . . 364 | | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 Sequence # 369 A 16-bit unsigned integer used to match the returned Service Path 370 Acknowledgement with the Service Path Update. 372 Reserved 374 This field is unused for now. The value MUST be initialized to 0 375 by the sender and MUST be ignored by the receiver. 377 Lifetime 378 16-bit unsigned integer. The number of time units remaining 379 before the service path MUST be considered expired. A value of 380 zero indicates that the Service Path MUST be deleted. A value of 381 0xFFFF indicates an infinite lifetime for the Service Path. One 382 time unit is 4 seconds. 384 Mobility Options 386 Variable-length field of such length that the complete Mobility 387 Header is an integer multiple of 8 octets long. This field 388 contains zero or more TLV-encoded mobility options. The receiver 389 MUST ignore and skip any options that it does not understand. 391 The following options are valid in a Service Path Acknowledgement: 393 - Network Service ID. 395 4.3. New Mobility options 397 4.3.1. Network Service ID 399 The Network Service ID option has the following format: 401 0 1 2 3 402 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | Type = TBA | Option Length | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | Service Path Identifier (SPI) | Service Index | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | | 409 + + 410 | | 411 + Network Service ID + 412 | | 413 + + 414 | | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 Option Type 419 TBA by IANA. 421 Option Length 423 8-bit unsigned integer. Length of the option, in octets, 424 excluding the Option Type and Option Length fields. 426 Service Path Identifier (SPI) 428 Uniquely identifies a Service Function Path (SFP). Participating 429 nodes MUST use this identifier for SFP selection. The initial 430 Classifier MUST set the appropriate SPI for a given classification 431 result. 433 Service Index (SI) 435 Provides location within the SFP. 437 Network Service ID 439 Variable length field that identifies the network service. 441 4.3.2. SFC node 443 The SFC node option has the following format: 445 0 1 2 3 446 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | Type = TBA | Option Length | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | Function ID Length | Node ID Length | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | | 453 + + 454 | | 455 + Function ID + 456 | | 457 + + 458 | | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | | 461 + + 462 | | 463 + Node ID + 464 | | 465 + + 466 | | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 Option Type 471 TBA by IANA. 473 Option Length 474 8-bit unsigned integer. Length of the option, in octets, 475 excluding the Option Type and Option Length fields. 477 Function ID Length 479 8-bit unsigned integer. Length of the Function ID field, in 480 octets. 482 Node ID Length 484 8-bit unsigned integer. Length of the Node ID field, in octets. 486 Function ID 488 Variable length field that identifies the function. 490 Node ID 492 Variable length field that identifies the node. 494 There might be multiple SFC node options in a Service Function Update 495 message, following the options the same order of the SFC/NS. 497 5. IANA Considerations 499 TBD. 501 6. Security Considerations 503 TBD. 505 7. Acknowledgments 507 The work in this draft has been partially supported by the H2020 508 5Growth (Grant 856709) and 5G-DIVE projects (Grant 859881). 510 8. References 512 8.1. Normative References 514 [I-D.bernardos-sfc-distributed-control] 515 Bernardos, C. J. and A. Mourad, "Distributed SFC control 516 for fog environments", Work in Progress, Internet-Draft, 517 draft-bernardos-sfc-distributed-control-05, 27 January 518 2022, . 521 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 522 Requirement Levels", BCP 14, RFC 2119, 523 DOI 10.17487/RFC2119, March 1997, 524 . 526 8.2. Informative References 528 [I-D.bernardos-sfc-fog-ran] 529 Bernardos, C. J. and A. Mourad, "Service Function Chaining 530 Use Cases in Fog RAN", Work in Progress, Internet-Draft, 531 draft-bernardos-sfc-fog-ran-10, 22 October 2021, 532 . 535 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 536 Chaining (SFC) Architecture", RFC 7665, 537 DOI 10.17487/RFC7665, October 2015, 538 . 540 Authors' Addresses 542 Carlos J. Bernardos 543 Universidad Carlos III de Madrid 544 Av. Universidad, 30 545 28911 Leganes, Madrid 546 Spain 547 Phone: +34 91624 6236 548 Email: cjbc@it.uc3m.es 549 URI: http://www.it.uc3m.es/cjbc/ 551 Alain Mourad 552 InterDigital Europe 553 Email: Alain.Mourad@InterDigital.com 554 URI: http://www.InterDigital.com/