1、 Rec. ITU-R M.2114 1 REPORT ITU-R M.2114 Key technical and operational characteristics for access technologies to support IP applications over land mobile systems (Question ITU-R 223/8) (2007) 1 Introduction With the high demand for Internet Protocol (IP) applications growing consistently at such hi
2、gh rates, the need to develop more efficient systems able to support new internet features will be a necessity. It is anticipated that users demands for mobile services are increasing with greater diversity and complexity for the mobile communications market. Diverse and complex services are expecte
3、d to have quite different traffic characteristics and QoS levels in comparison to voice traffic or text. In addition, increasing demands on multimedia services causes further more complexity in designing and developing the future mobile systems. Future mobile technologies should support diverse serv
4、ices with different traffic characteristics which are pervasive regardless of air interface technologies. IP applications are accepted as one of solutions to provide affordable and compatible services as used in wired communication systems. Therefore, IP applications over mobile systems will be impo
5、rtant in the future due to global interoperability. IP applications over mobile systems are supported by existing standards that use IP to send data. However, to support enhanced IP applications over mobile systems such as seamless delivery of multimedia data services, several significant technical
6、characteristics in the radio interface and access networks should be considered. The All IP Network (AIPN) is an IP-based network providing common capabilities that are independent to the type of service being provided and the access system being used. Convergence to IP technology within the AIPN sy
7、stem design should be considered for the system as a whole with minimum duplication of functionality. During the initial stages of AIPN introduction it is likely that earlier systems and terminals will exist in parallel with AIPNs. Therefore, the AIPN should be able to support access networks contai
8、ning Circuit Switched (CS) terminals and accommodate access systems based on CS. Interworking and interconnection with CS networks should be provided. The AIPN should be designed to enable efficient coexistence with earlier PS domains. 2 Scope This Report defines the essential technical and operatio
9、nal characteristics needed to support IP applications over mobile systems. 2 Rec. ITU-R M.2114 3 References 3.1 Related ITU-R Recommendations and Reports Recommendation ITU-R M.1079 Performance and quality of service requirements for IMT-2000 access networks Recommendation ITU-R M.1741 Methodology f
10、or deriving performance objectives and its optimization for IP packet applications in the mobile-satellite service. Recommendation ITU-R S.1711 Performance enhancements of transmission control protocol (TCP) over satellite networks (pre-published) Recommendation ITU-R M.1645 Framework and overall ob
11、jectives of the future development of IMT-2000 and systems beyond IMT-2000 Report ITU-R F.2058 Design techniques applicable to broadband fixed wireless access (FWA) systems conveying Internet protocol (IP) packets or asynchronous transfer mode (ATM) cells. 3.2 IETF The following references provide s
12、upporting information and do not refer to specific implementations. IETF RFCs are available from the IETF web site, http:/www.ietf.org/rfc. RFC 791 Internet Protocol, Sept. 1981. RFC 793 Transmission Control Protocol, September 1981. RFC 1035 Domain Names Implementation and Specification, November 1
13、987. RFC 1661 The Point-to-Point Protocol (PPP), July 1994. RFC 2002 IP Mobility support, October 1996. RFC 2068 Hypertext Transfer Protocol - HTTP/1.1, January 1997. RFC 2131 Dynamic Host Configuration Protocol, March 1997. RFC 2460 Internet Protocol, Version 6 (IPv6) Specification, December 1998.
14、RFC 3095 Borman, et al, “RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed”, July 2001. RFC 3545 Koren, et al, “Enhanced Compressed RTP(CRTP) for links with High Delay, Packet Loss and Reordering”, July 2003. 4 Definition AIPN: A collection of entities th
15、at provide a set of capabilities for the provision of IP services to users based on IP technology where various access systems can be connected. The AIPN provides a set of common capabilities (including mobility, security, service provisioning, charging and QoS) which enable the provision of service
16、s to users and connectivity to other external networks. An AIPN requires one or more connected access systems to allow users to access the AIPN. Mobile IPv4: Provides mobility support for IPv4. Mobile IPv6: Provides mobility support for IPv6. Rec. ITU-R M.2114 3 5 Abbreviations AAA Authentication, a
17、uthorization, and accounting AIPN All IP network BR Border router CN Correspondent node DHCP Dynamic Host Control Protocol E2E QoS End-to-end quality of service HA Home agent HAAA Home AAA HDB Home data base IETF Internet Engineering Task Force IMS IP multimedia subsystem LAC Link access control MAC
18、 Media access control MIPv4 Mobile IPv4 MIPv6 Mobile IPv6 MMD Multi-media domain MS Mobile station PDF Policy decision function PDSN/AGW Packet data serving node/access gateway PDU Protocol data unit PPP Point-to-Point Protocol SLA Service level agreement VAAA Visited AAA VDB Visited data base P-CSC
19、F Proxy-call session control function PDSN Packet data serving node S-CSCF Serving-call session control function RAN Radio access network 6 Basic capabilities 6.1 Key characteristics 6.1.1 Technical characteristics Essential key characteristics to support IP applications over mobile systems include:
20、 Compatibility 4 Rec. ITU-R M.2114 Transparency Scalability and efficiency Security High speed burst traffic Low cost per bits Seamless delivery services Various grade of services. IP applications over mobile systems must be able to remain compatible to all levels used for the standard non-mobile IP
21、 applications. IP applications over mobile systems should therefore remain “invisible” for higher level protocols and applications. Higher layers should continue to function normally even while the mobile has altered its point of attachment to the network. As new features are developed, the sub-netw
22、ork (subnet) should also function with maximum efficiency and minimum complexity. As the user rates of mobile communications increase, IP applications over mobile systems should be scalable over the large numbers utilizing the Internet. These subnets should also be able to provide support for advanc
23、ed Internet features as Multicasting and quality of service (QoS). Identification during attachment, authentication and authorization are required in order to protect against remote attacks. As information is transmitted from node to node, the location of a mobile node must be authenticated to maint
24、ain security. 6.1.2 Operational characteristics The AIPN should be under the control of the operator of the AIPN. The AIPN should provide common mechanisms for the AIPN operator to control access to and usage of AIPN resources. 6.2 Encapsulation The Internet Protocol Version 4, IPv4, is described in
25、 IETF RFC 791. Internet Protocol Version 6, IPv6, is described in IETF RFC 2460. Figure 1 illustrates the protocol hierarchy. Rec. ITU-R M.2114 5 FIGURE 1 Protocol hierarchy All IP application related data is exchanged between hosts in IP packets. For example, the Hypertext Transfer Protocol (RFC 20
26、68) protocol data unit, PDU, is encapsulated in a Transmission Control Protocol (RFC 793) PDU, which is encapsulated in an IP PDU, and then finally in a local network PDU. In the context of mobile systems, the local network may be considered the radio interface. 6.3 Address management To participate
27、 effectively in an IP network, a device must possess an IP address. IP packets are routed based on the destination address field within the packet header. IPv4 addresses are 32-bit binary numbers. Most commonly, they are expressed by considering the 32 bits as four octets, converting each octet to d
28、ecimal, then separating these numbers with dots to create dotted decimal notation. For example, the address 17.112.152.32 is the dotted decimal notation of: 0001000101110000100110000010000000010001011100001001100000100000IPv6 addresses are 128-bit binary numbers. If these addresses are expresses in
29、human readable form they are most commonly expressed in hexadecimal with colons to aid legibility, for example: fe80:0000:0000:0000:020a:95ff:fef3:2e91. In order to interwork between Internet and wireless systems, the mapping between IP addresses and MAC addresses should be considered. For example,
30、IP address of 255.255.255.255 is mapped to the MAC address of ff:ff:ff:ff:ff:ff for data broadcasting in wireless LAN systems. 6 Rec. ITU-R M.2114 6.4 Maximum transmission units (MTUs) and IP fragmentation IPv4 packets (datagrams) vary in size, from 20 bytes (the size of the IPv4 header alone) to a
31、maximum of 65 535 bytes. Subnets need not support maximum-sized (64 kB) IP packets, as IP provides a scheme that breaks packets that are too large for a given subnet into fragments that travel as independent IP packets and are reassembled at the destination. The maximum packet size supported by a su
32、bnet is known as its maximum transmission unit (MTU). 6.5 Multicasting/Broadcasting The Internet model includes “multicasting”, where IP packets are sent to all the members of a multicast group. Multicast is an option in IPv4, but a standard feature of IPv6. IPv4 multicast is currently used by multi
33、media, teleconferencing, gaming, and file distribution (web, peer-to-peer sharing) applications, as well as by some key network and host protocols (e.g. RIPv2, OSPF, NTP). IPv6 additionally relies on multicast for network configuration (DHCP-like autoconfiguration) and link-layer address discovery (
34、replacing ARP). In the case of IPv6, this can allow autoconfiguration and address discovery to span across routers, whereas the IPv4 broadcast-based services cannot without ad-hoc router support. Alternatively MBMS (multimedia broadcast and multicast service) has been developed in mobile systems. Th
35、e broadcast mode in MBMS differs from the multicast mode in that there is no specific requirement to activate or subscribe to the MBMS in broadcast mode. The broadcast mode is intended to efficiently use radio/network resources e.g. data is transmitted over a common radio channel. Data is transmitte
36、d in the broadcast service area as defined by the network. The reception of the traffic in the broadcast mode is not guaranteed. 6.6 Bandwidth on demand (BoD) subnets Some subnets allow a number of subnet nodes to share a channel efficiently by assigning transmission opportunities dynamically. Trans
37、mission opportunities are requested by a subnet node when it has packets to send. The subnet schedules and grants transmission opportunities sufficient to allow the transmitting subnet node to send one or more packets (or packet fragments). These subnets are referred to as Bandwidth on demand (BoD)
38、subnets. 6.7 Bandwidth asymmetries Some subnets may provide asymmetric bandwidth (or may cause TCP packet flows to experience asymmetry in the capacity) and the Internet protocol suite will generally still work fine. However, there is a case when such a scenario reduces TCP performance. Since TCP da
39、ta segments are “clocked” out by returning acknowledgments, TCP senders are limited by the rate at which ACKs can be returned. Therefore, when the ratio of the available capacity of the Internet path carrying the data to the bandwidth of the return path of the acknowledgments is too large, the slow
40、return of the ACKs directly impacts performance. Since ACKs are generally smaller than data segments, TCP can tolerate some asymmetry, but as a general rule, designers of subnets should be aware that subnets with significant asymmetry can result in reduced performance, unless issues are taken to mit
41、igate this (RFC3449). Several strategies have been identified for reducing the impact of asymmetry of the network path between two TCP end hosts, e.g. (RFC3449). These techniques attempt to reduce the number of ACKs transmitted over the return path (low bandwidth channel) by changes at the end host(
42、s), and/or by modification of subnet packet forwarding. While these solutions may mitigate the performance issues caused by asymmetric subnets, they do have associated cost and may have other implications. A fuller discussion of strategies and their implications is provided in (RFC3449). Rec. ITU-R
43、M.2114 7 7 QoS considerations Some of the general requirements for QoS should include: End-to-end QoS. Wide range of QoS-enabled services. End-to-end QoS should be supported within the local domain and across different network domains as well. Appropriate levels of QoS should be maintained even when
44、 Internet features, such as multicasting is applied. The QoS network architecture should be flexible enough to support different QoS control mechanisms, which are defined in different access technology environments. The network should be able to provide mechanisms which could perform traffic and con
45、gestion control. Traffic control would include functions such as network resource management, packet marking, traffic shaping, and packet scheduling. Congestion control refers to functions which include packet discarding or explicit congestion notification. The network should also provide methods in
46、 which to negotiate QoS at both transport and service layers, and allow dynamic alterations of the QoS parameters. The network should allow operators to implement QoS policy control, where the policy-based management would be extended across multiple domains to ensure QoS. It is generally recognized
47、 that specific service guarantees are needed to support real-time multimedia, toll-quality telephony, and other performance-critical applications1. For some important services with strict end-to-end QoS requirements, such as conversational speech or streaming video, the QoS should be assured in case
48、 of integrated networking with different IP network domains or backbone networks. Most likely this would be ensured on a per service basis of specific flows of IP packets having been identified by the service. There are at least two architectural approaches to providing mechanisms for QoS support in
49、 the Internet. The IP integrated services (Intserv) (RFC1633) is a working group formed to standardize a new resource allocation architecture and new service models for the Internet. The Intserv model includes two main components: the traffic control and the ReSerVation Protocol. Flows are identified by a flow specification (flowspec), which creates a stateful association between individual packets by matching fields in the packet header. Capacity is reserved for the flow, and appropriate traffic conditioning and scheduling is i
