1、 I n t e r n a t i o n a l T e l e c o m m u n i c a t i o n U n i o n ITU-T Y.2040 TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (02/2016) SERIES Y: GLOBAL INFORMATION INFRASTRUCTURE, INTERNET PROTOCOL ASPECTS AND NEXT-GENERATION NETWORKS Next Generation Networks Frameworks and functional archite
2、cture models Flow-based service continuity in multi-connection Recommendation ITU-T Y.2040 ITU-T Y-SERIES RECOMMENDATIONS GLOBAL INFORMATION INFRASTRUCTURE, INTERNET PROTOCOL ASPECTS AND NEXT-GENERATION NETWORKS GLOBAL INFORMATION INFRASTRUCTURE General Y.100Y.199 Services, applications and middlewa
3、re Y.200Y.299 Network aspects Y.300Y.399 Interfaces and protocols Y.400Y.499 Numbering, addressing and naming Y.500Y.599 Operation, administration and maintenance Y.600Y.699 Security Y.700Y.799 Performances Y.800Y.899 INTERNET PROTOCOL ASPECTS General Y.1000Y.1099 Services and applications Y.1100Y.1
4、199 Architecture, access, network capabilities and resource management Y.1200Y.1299 Transport Y.1300Y.1399 Interworking Y.1400Y.1499 Quality of service and network performance Y.1500Y.1599 Signalling Y.1600Y.1699 Operation, administration and maintenance Y.1700Y.1799 Charging Y.1800Y.1899 IPTV over
5、NGN Y.1900Y.1999 NEXT GENERATION NETWORKS Frameworks and functional architecture models Y.2000Y.2099 Quality of Service and performance Y.2100Y.2199 Service aspects: Service capabilities and service architecture Y.2200Y.2249 Service aspects: Interoperability of services and networks in NGN Y.2250Y.2
6、299 Enhancements to NGN Y.2300Y.2399 Network management Y.2400Y.2499 Network control architectures and protocols Y.2500Y.2599 Packet-based Networks Y.2600Y.2699 Security Y.2700Y.2799 Generalized mobility Y.2800Y.2899 Carrier grade open environment Y.2900Y.2999 FUTURE NETWORKS Y.3000Y.3499 CLOUD COMP
7、UTING Y.3500Y.3999 INTERNET OF THINGS AND SMART CITIES AND COMMUNITIES General Y.4000Y.4049 Definitions and terminologies Y.4050Y.4099 Requirements and use cases Y.4100Y.4249 Infrastructure, connectivity and networks Y.4250Y.4399 Frameworks, architectures and protocols Y.4400Y.4549 Services, applica
8、tions, computation and data processing Y.4550Y.4699 Management, control and performance Y.4700Y.4799 Identification and security Y.4800Y.4899 For further details, please refer to the list of ITU-T Recommendations. Rec. ITU-T Y.2040 (02/2016) i Recommendation ITU-T Y.2040 Flow-based service continuit
9、y in multi-connection Summary Recommendation ITU-T Y.2040 describes the flow-based service continuity mechanism in a multi-connection environment. This Recommendation also covers scenarios, requirements, solutions, information flows and security. In the multi-connection environment, flow-based servi
10、ce continuity is the mechanism that allows the moving of IP flows from one access to another (target) access, thus minimising service disruption in the case of access loss, or when the access is no longer usable. Flow-based service continuity (FSC) includes two modes, the multi-connection user equip
11、ment (MUE) initiated flow-based service continuity mode and the network-initiated flow-based service continuity mode. History Edition Recommendation Approval Study Group Unique ID* 1.0 ITU-T Y.2040 2016-02-13 13 11.1002/1000/12704 Keywords Flow-based, multi-connection, service continuity. * To acces
12、s the Recommendation, type the URL http:/handle.itu.int/ in the address field of your web browser, followed by the Recommendations unique ID. For example, http:/handle.itu.int/11.1002/1000/11830-en. ii Rec. ITU-T Y.2040 (02/2016) FOREWORD The International Telecommunication Union (ITU) is the United
13、 Nations specialized agency in the field of telecommunications, information and communication technologies (ICTs). The ITU Telecommunication Standardization Sector (ITU-T) is a permanent organ of ITU. ITU-T is responsible for studying technical, operating and tariff questions and issuing Recommendat
14、ions on them with a view to standardizing telecommunications on a worldwide basis. The World Telecommunication Standardization Assembly (WTSA), which meets every four years, establishes the topics for study by the ITU-T study groups which, in turn, produce Recommendations on these topics. The approv
15、al of ITU-T Recommendations is covered by the procedure laid down in WTSA Resolution 1. In some areas of information technology which fall within ITU-Ts purview, the necessary standards are prepared on a collaborative basis with ISO and IEC. NOTE In this Recommendation, the expression “Administratio
16、n“ is used for conciseness to indicate both a telecommunication administration and a recognized operating agency. Compliance with this Recommendation is voluntary. However, the Recommendation may contain certain mandatory provisions (to ensure, e.g., interoperability or applicability) and compliance
17、 with the Recommendation is achieved when all of these mandatory provisions are met. The words “shall“ or some other obligatory language such as “must“ and the negative equivalents are used to express requirements. The use of such words does not suggest that compliance with the Recommendation is req
18、uired of any party. INTELLECTUAL PROPERTY RIGHTSITU draws attention to the possibility that the practice or implementation of this Recommendation may involve the use of a claimed Intellectual Property Right. ITU takes no position concerning the evidence, validity or applicability of claimed Intellec
19、tual Property Rights, whether asserted by ITU members or others outside of the Recommendation development process. As of the date of approval of this Recommendation, ITU had not received notice of intellectual property, protected by patents, which may be required to implement this Recommendation. Ho
20、wever, implementers are cautioned that this may not represent the latest information and are therefore strongly urged to consult the TSB patent database at http:/www.itu.int/ITU-T/ipr/. ITU 2016 All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the
21、prior written permission of ITU. Rec. ITU-T Y.2040 (02/2016) iii Table of Contents Page 1 Scope . 1 2 References . 1 3 Definitions 1 3.1 Terms defined elsewhere 1 3.2 Terms defined in this Recommendation . 2 4 Abbreviations and acronyms 2 5 Conventions 3 6 Scenarios and requirements 3 6.1 Scenarios
22、. 3 6.2 Requirements 4 7 Flow-based service continuity mechanisms . 5 7.1 Overview 5 7.2 Description of the mechanisms 6 7.3 Capability requirements 7 7.4 Procedures 8 Bibliography. 11 Rec. ITU-T Y.2040 (02/2016) 1 Recommendation ITU-T Y.2040 Flow-based service continuity in multi-connection 1 Scope
23、 This Recommendation describes the flow-based service continuity mechanism in a multi-connection environment. This Recommendation also describes scenarios, requirements, information flow mechanisms and security of flow-based service continuity in a multi-connection environment. For information on ot
24、her aspects outside of the scope of this Recommendation, such as security and charging for flow-based service continuity in a multi-connection environment, see ITU-T Y.2251. 2 References The following ITU-T Recommendations and other references contain provisions which, through reference in this text
25、, constitute provisions of this Recommendation. At the time of publication, the editions indicated were valid. All Recommendations and other references are subject to revision; users of this Recommendation are therefore encouraged to investigate the possibility of applying the most recent edition of
26、 the Recommendations and other references listed below. A list of the currently valid ITU-T Recommendations is regularly published. The reference to a document within this Recommendation does not give it, as a stand-alone document, the status of a Recommendation. ITU-T Y.2027 Recommendation ITU-T Y.
27、2027 (2012), Functional architecture of multi-connection. ITU-T Y.2028 Recommendation ITU-T Y.2028 (2015), Intelligent access selection in multi-connection. ITU-T Y.2029 Recommendation ITU-T Y.2029 (2015), A multi-path transmission control in multi-connection. ITU-T Y.2251 Recommendation ITU-T Y.225
28、1 (2011), Multi-connection requirements. 3 Definitions 3.1 Terms defined elsewhere This Recommendation uses the following terms defined elsewhere: 3.1.1 connection b-ITU-T X.200: A connection is an association established for the transfer of data between two or more peer-(N)-entities. This associati
29、on binds the peer-(N)-entities together with the (N-1)-entities in the next lower layer. 3.1.2 multi-connection b-ITU-T Y.2252: The collection of several connections between two or more peer-(N)-entities simultaneously. At least one of the connections is associated with a physical layer connectivity
30、 different from the rest of the connections. All connections are coordinated with each other to provide service to higher layer entities. 3.1.3 multi-connection user equipment (MUE) ITU-T Y.2027: A user equipment which can support two or more network connections simultaneously under the control of a
31、 network enhanced for multi-connection capability. 3.1.4 service continuity b-ITU-T Q.1706: The ability for a moving object to maintain ongoing service including over current states, such as users network environment and session for a service. 2 Rec. ITU-T Y.2040 (02/2016) 3.1.5 service transfer ITU
32、-T Y.2251: Act of moving, one or more services or service components belonging to a single multi-connection UE, from one access network associated with one interface of the multi-connection UE to another access network(s) associated with other interface(s) of the multi-connection UE. 3.1.6 IP flow b
33、-RFC 3917: A flow is defined as a set of IP packets passing an observation point in the network during a certain time interval. All packets belonging to a particular flow have a set of common properties. Each property is defined as the result of applying a function to the values of: 1) One or more p
34、acket header field (e.g., destination IP address), transport header field (e.g., destination port number), or application header field (e.g., RTP header fields b-RFC 3550); 2) One or more characteristics of the packet itself (e.g., number of MPLS labels, etc.); 3) One or more of fields derived from
35、packet treatment (e.g., next hop IP address, the output interface, etc.). 3.2 Terms defined in this Recommendation None. 4 Abbreviations and acronyms This Recommendation uses the following abbreviations and acronyms: 2G Second Generation 3G Third Generation 3GPP 3rd Generation Partnership Project AC
36、-FE Access Control FE FE Functional Entity FSC Flow-based Service Continuity IAS Intelligent Access Selection IP Internet Protocol MC-FE Multi-connection Coordination FE MAS-F Multi-connection Application Support Function MMF Multi-connection Media Function MPC-FE Multi-connection Policy Control FE
37、MR-FE Multi-connection Registration FE MTC-FE Multi-connection Terminal Control FE MUE Multi-connection User Equipment MUP-FE Multi-connection User Profile FE QOS Quality of Service SC Service Continuity SCF Service Control Function WLAN Wireless Local Area Network Rec. ITU-T Y.2040 (02/2016) 3 5 Co
38、nventions In this Recommendation: The keywords “is required to“ indicate a requirement which must be strictly followed and from which no deviation is permitted if conformance to this document is to be claimed. The keywords “is prohibited from“ indicate a requirement which must be strictly followed a
39、nd from which no deviation is permitted if conformance to this document is to be claimed. The keywords “is recommended“ indicate a requirement which is recommended but which is not absolutely required. Thus this requirement need not be present to claim conformance. The keywords “is not recommended“
40、indicate a requirement which is not recommended but which is not specifically prohibited. Thus, conformance with this specification can still be claimed even if this requirement is present. The keywords “can optionally“ indicate an optional requirement which is permissible, without implying any sens
41、e of being recommended. This term is not intended to imply that the vendors implementation must provide the option and the feature can be optionally enabled by the network operator/service provider. Rather, it means the vendor may optionally provide the feature and still claim conformance with the s
42、pecification. 6 Scenarios and requirements 6.1 Scenarios In the multi-connection environment, the multi-connection user equipment (MUE) has more than one active connection simultaneously, it can send and receive different IP flows of the same application through different accesses. In the case where
43、 one of the accesses is lost or is no longer usable, a mechanism is provided to move the IP flows to another (target) access in order to minimise service disruption. When an access is recovered, a mechanism is provided to move the IP flow over to the recovered access. Precedence is given to those ac
44、cesses associated with policies. The covered scenarios include an MUE-initiated flow-based service continuity (FSC) scenario and a network-initiated FSC scenario. 6.1.1 MUE-initiated FSC scenario In the MUE-initiated FSC mode only the MUE controls the traffic routing for the associated multi-connect
45、ions and applying policies for FSC rules. The MUE can request to move selected IP flows from an old access to a new access by sending one or more routing rules to the network. The routing rules specify the selected IP flows and the new access. The MUE determines the routing rules and provides them t
46、o the network. The network may either accept or reject the routing rules requested by the MUE, but it does not provide routing rules by itself. 6.1.2 Network-initiated FSC scenario In the network-initiated FSC mode, the network controls the traffic routing within the multi-connections. The network d
47、etermines the routing rules and provides them to the MUE. The MUE may either accept or reject the networks request for routing rules (e.g., based on the suitability of the access link conditions), but the MUE does not provide routing rules by itself. 4 Rec. ITU-T Y.2040 (02/2016) 6.2 Requirements 6.
48、2.1 General requirements In the multi-connection environment, the MUE may transfer one or multiple IP sub-flows seamlessly when the MUE moves out of coverage and the connection is lost, or when there is network congestion. This clause identifies requirements in order to provide service continuity to
49、 the user and the application during service transfer: 1) Data forwarding mechanism: A data forwarding mechanism is required to keep data integrity. 2) Mobility control mechanism: A mobility control mechanism is required to minimize the time during the flow transfer and maintain flow service continuity. 3) Flow sequence numbers: sub-flow sequence numbers need to be added to each sub-flow. A flow sequence number is used for transmission control and data recovery at the receiving end. 4) The multi-connection p
