Digital Enhanced Cordless Telecommunications (DECT); Integrated Services Digital Network (ISDN); ISDN Mobility protocol Interworking specification Profile (IMIP); Part 1: DECT/ISDN interworking for Cordless Terminal Mobility (CTM) support

This standard specifies a set of technical requiremens for Digital Enhanced Cordless Telecommunications (DECT) Fixed Parts (FP) supporting connection, via an ISDN interface, to a network supporting terminal mobility. This part 1 of this standard specifies the interworking procedures between the DECT air interface and the mobility management protocols defined for ISDN interface, to support CTM mobility. Part 2 of this standard (DEN/DECT-010066) specifies the interworking procedures between the DECT air interface and the mobility management protocols defined for an enhanced ISDN interface, to support GSM mobility.  The ETS 300 434 contains interworking requirements for the support of basic call.

Digitalne izboljšane brezvrvične telekomunikacije (DECT) - Digitalno omrežje z integriranimi storitvami (ISDN) - Profil specifikacije medsebojnega delovanja za protokol mobilnosti ISDN (IMIP) - 1. del: Medsebojno delovanje DECT/ISDN za podporo mobilnosti brezvrvičnega terminala (CTM)

General Information

Status
Published
Publication Date
30-Jun-2000
Current Stage
6060 - National Implementation/Publication (Adopted Project)
Start Date
01-Jul-2000
Due Date
01-Jul-2000
Completion Date
01-Jul-2000
Standard
PSIST EN 301 361-1:2000
English language
50 pages
sale 10% off
Preview
sale 10% off
Preview
e-Library read for
1 day
Standard
SIST EN 301 361-1:2000
English language
50 pages
sale 10% off
Preview
sale 10% off
Preview
e-Library read for
1 day

Standards Content (Sample)


2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.Digital Enhanced Cordless Telecommunications (DECT); Integrated Services Digital Network (ISDN); ISDN Mobility protocol Interworking specification Profile (IMIP); Part 1: DECT/ISDN interworking for Cordless Terminal Mobility (CTM) support33.080Digitalno omrežje z integriranimi storitvami (ISDN)Integrated Services Digital Network (ISDN)33.070.30'(&7Digital Enhanced Cordless Telecommunications (DECT)ICS:Ta slovenski standard je istoveten z:EN 301 361-1 V1.1.13SIST EN 301 361-1:2000en01-PDM-20003SIST EN 301 361-1:2000SLOVENSKI
STANDARD
ETSIETSI EN 301 361-1 V1.1.1 (1999-10)2ReferenceDEN/DECT-030126 (clo90ico.PDF)KeywordsCTM, DECT, DSS1+, interworking, ISDN, mobilityETSIPostal addressF-06921 Sophia Antipolis Cedex - FRANCEOffice address650 Route des Lucioles - Sophia AntipolisValbonne - FRANCETel.: +33 4 92 94 42 00
Fax: +33 4 93 65 47 16Siret N° 348 623 562 00017 - NAF 742 CAssociation à but non lucratif enregistrée à laSous-Préfecture de Grasse (06) N° 7803/88Internetsecretariat@etsi.frIndividual copies of this ETSI deliverablecan be downloaded fromhttp://www.etsi.orgIf you find errors in the present document, send yourcomment to: editor@etsi.frCopyright NotificationNo part may be reproduced except as authorized by written permission.The copyright and the foregoing restriction extend to reproduction in all media.© European Telecommunications Standards Institute 1999.All rights reserved.SIST EN 301 361-1:2000

ETSIETSI EN 301 361-1 V1.1.1 (1999-10)3ContentsIntellectual Property Rights.5Foreword.5Introduction.51Scope.62References.63Definitions, symbols and abbreviations.73.1Definitions.73.2Symbols.73.3Abbreviations.84Feature definitions.84.1Network (NWK) features.84.1.1Application features.85General requirements.85.1Architecture.85.1.1Reference configuration.85.1.2Interfaces.95.2Protocol model.95.3Identity usage.105.3.1CTM identity.105.3.2CTM number.105.3.3FP- address.106Interoperability requirements.106.1General.106.2DECT NWK features.116.3Application features.116.4NWK feature to procedure mapping.126.5Application feature to procedure mapping.137Procedure descriptions.147.1Connection establishment and release.147.1.1NCICs connection control.147.1.2Connection establishment co-ordination.147.1.2.1PT initiated mobility management transaction.147.1.2.2Network initiated mobility management transaction.157.1.3Connection oriented data transfer co-ordination.167.1.4Connection release co-ordination.177.2Mobility management procedures.187.2.1Generic interworking procedures, network initiated transaction, explicit acknowledgement.187.2.1.1FT accepts mobility management request.187.2.1.2FT receives response from PT.197.2.1.3FT rejects mobility management request.197.2.2Generic interworking procedures, network initiated transaction, no explicit acknowledgement.197.2.2.1FT accepts mobility management request.197.2.2.2FT rejects mobility management request.207.2.3Generic interworking procedures, PT initiated transaction, explicit acknowledgement.207.2.3.1FT accepts mobility management request.207.2.3.2FT receives response from network.207.2.3.3FT rejects mobility management request.207.2.4Generic interworking procedures, PT initiated transaction with no explicit acknowledgement.217.2.4.1FT accepts mobility management request.217.2.4.2FT rejects mobility management request.217.2.5Identification of PT.22SIST EN 301 361-1:2000

ETSIETSI EN 301 361-1 V1.1.1 (1999-10)47.2.6Authentication of network.237.2.7Authentication of PT.247.2.8Location registration.257.2.8.1FT initiates temporary identity assignment.257.2.8.2FT receives temporary reject from network.267.2.9Location update.267.2.10Obtaining access rights.267.2.11On air key allocation.277.2.11.1FT accepts or rejects mobility management request.277.2.11.2FT receives positive response from PT.287.2.11.3FT receives negative response from PT.287.2.11.4FT receives authentication response from network.297.2.12FT terminating access rights.297.2.13Network initiated ciphering.297.2.14Portable initiated ciphering.307.3Call control procedures.317.3.1General.317.3.2Outgoing call.317.3.3Incoming call.347.3.4Call progress information transfer.387.3.5Call release.387.3.5.1Network initiated release.397.3.5.2PT initiated release.407.3.5.3Other release cases.407.3.6Keypad information transfer.417.4Other interworking procedures.417.4.1Interaction in-between MM transactions.417.4.2Interactions between MM- and CC- transactions.417.4.3Other interactions between local and interworked procedures.427.4.4Error handling.428Message mappings.428.1General.428.2Mobility management message/component mapping.438.2.1MM component to DECT message.438.2.2DECT message to MM component.438.3Call control message mapping.448.3.1DSS1 message to DECT message.448.3.2DECT message to DSS1 message.448.4Information element/parameter mapping.458.4.1CTM information element/parameter to DECT information element.458.4.1.1General/transparent mapping.458.4.1.2<_componentType>+ <_operation> - << message type>>.468.4.1.3<_cTMIdentityType> - <>.468.4.1.4<_invokeIdentifier> - << transaction identifier>>.478.4.2DECT information element to CTM information element/parameter.478.4.2.1General/transparent mapping.478.4.2.2Fixed identity + location area - _cTMOldLocationAreaIdentity.478.4.2.3Message type - _componentType+ _operation.488.4.2.4Transaction identifier - _invokeIdentifier.48Bibliography.49History.50SIST EN 301 361-1:2000

ETSIETSI EN 301 361-1 V1.1.1 (1999-10)5Intellectual Property RightsIPRs essential or potentially essential to the present document may have been declared to ETSI. The informationpertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be foundin SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respectof ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web server(http://www.etsi.org/ipr).Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guaranteecan be given as to the existence of other IPRs not referenced in SR 000 314 (or the updates on the ETSI Web server)which are, or may be, or may become, essential to the present document.ForewordThis European Standard (Telecommunications series) has been produced by ETSI Project Digital Enhanced CordlessTelecommunications (DECT).The present document is part 1 of a multi-part EN covering the ISDN Mobility protocol Interworking specificationProfile (IMIP), as identified below:Part 1:"DECT/ISDN interworking for Cordless Terminal Mobility (CTM) support";Part 2:"DECT/ISDN interworking for Global System for Mobile communications (GSM) support".National transposition datesDate of adoption of this EN:27 August 1999Date of latest announcement of the present document (doa):30 November 1999Date of latest publication of new National Standardor endorsement of the present document (dop/e):31 May 2000Date of withdrawal of any conflicting National Standard (dow):31 May 2000IntroductionThis two-part EN defines a profile for interworking between a DECT system and an Integrated Services Digital Network(ISDN) using the enhanced Digital Subscriber Signalling No. 1 (DSS1) protocol defined in EN 301 144-1 [8]. ThisISDN protocol enables cordless terminals to have access to an ISDN infrastructure.Part one defines the DECT/DSS1+ interworking for the CTM support.Part two considers the DECT/DSS1+ interworking for the GSM support.The present document specifies how DSS1+ procedures and information are mapped over the DECT air interface, andhow they are provided and used by the DECT Fixed Part.SIST EN 301 361-1:2000

ETSIETSI EN 301 361-1 V1.1.1 (1999-10)61ScopeThe present document specifies a set of technical requirements for Digital Enhanced Cordless Telecommunications(DECT) Fixed Parts (FP) supporting connection, via an ISDN interface, to a network supporting terminal mobility.The standard covers the requirements necessary for the support of Cordless Terminal Mobility (CTM) Phase 1 (Part 1)and for the support of the DECT access to GSM via ISDN interfaces (Part 2). In both of these scenarios, the FT isconnected to the network via the alpha interface, as specified in EN 301 144-1 [8].NOTE:For CTM phase 1, the Portable Part (PP) requirements are specified in EN 300 444 [6].The present document specifies the interworking procedures between the Digital Enhanced CordlessTelecommunications (DECT) air interface and the mobility management protocols defined for Integrated ServicesDigital Network (ISDN) interfaces.The ISDN Access Profile (IAP), ETS 300 434-2 [12], specifies the requirements for the support of ISDN services. Apartfrom the mobility management procedures, that are covered in the present document, the IAP includes interworkingspecifications for the support of basic call.2ReferencesThe following documents contain provisions which, through reference in this text, constitute provisions of the presentdocument.· References are either specific (identified by date of publication, edition number, version number, etc.) ornon-specific.· For a specific reference, subsequent revisions do not apply.· For a non-specific reference, the latest version applies.· A non-specific reference to an ETS shall also be taken to refer to later versions published as an EN with the samenumber.[1]EN 300 175-1: "Digital Enhanced Cordless Telecommunications (DECT); Common Interface (CI);Part 1: Overview".[2]EN 300 175-2: "Digital Enhanced Cordless Telecommunications (DECT); Common Interface (CI);Part 2: Physical Layer (PHL)".[3]EN 300 175-3: "Digital Enhanced Cordless Telecommunications (DECT); Common Interface (CI);Part 3: Medium Access Control (MAC) Layer".[4]EN 300 175-4: "Digital Enhanced Cordless Telecommunications (DECT); Common Interface (CI);Part 4: Data Link Control (DLC) Layer".[5]EN 300 175-5: "Digital Enhanced Cordless Telecommunications (DECT); Common Interface (CI);Part 5: Network (NWK) Layer".[6]EN 300 444: "Digital Enhanced Cordless Telecommunications (DECT); Generic Access Profile(GAP)".[7]EN 300 403-1: "Integrated Services Digital Network (ISDN); Digital Subscriber Signalling SystemNo. one (DSS1) protocol; Signalling network layer for circuit-mode basic call control;Part 1: Protocol specification [ITU-T Recommendation Q.931 (1993), modified]".[8]EN 301 144-1: "Integrated Services Digital Network (ISDN); Digital Subscriber Signalling SystemNo. one (DSS1) and Signalling System No.7 (SS7); Signalling application for the mobilitymanagement service on the alpha interface; Part 1: Protocol specification".SIST EN 301 361-1:2000

ETSIETSI EN 301 361-1 V1.1.1 (1999-10)7[9]ISO/IEC 9646-7 (1995): "Information technology - Open Systems Interconnection - Conformancetesting methodology and framework - Part 7: Implementation Conformance Statements".[10]CCITT Recommendation X.219 (1988): "Remote operation: Model, notation and servicedefinition".[11]EN 301 061-1 (1.2.2): "Integrated Services Digital Network (ISDN); Digital Subscriber SignallingSystem No. one (DSS1) protocol; Generic functional protocol for the support of supplementaryservices at the "b" service entry point for Virtual Private Network (VPN) applications; Part 1:Protocol specification".[12]ETS 300 434-2: "Digital Enhanced Cordless Telecommunications (DECT); Integrated ServicesDigital Network (ISDN); DECT/ISDN interworking for end system configuration; Part 2: Accessprofile".[13]CCITT Recommendation I.411 (1988): "ISDN user-network interfaces; Reference configurations".[14]ETS 300 402-1: "Integrated Services Digital Network (ISDN); Digital Subscriber SignallingSystem No. one (DSS1) protocol; Data link layer; Part 1: General aspects [ITU-TRecommendation Q.920 (1993), modified]".[15]ETS 300 011-1: "Integrated Services Digital Network (ISDN); Primary rate User-NetworkInterface (UNI); Part 1: Layer 1 specification".[16]ETS 300 012-1: "Integrated Services Digital Network (ISDN); Basic user-network interface;Layer 1 specification and test principles; Part 1: Layer 1 specification".[17]EN 301 175: "Cordless Terminal Mobility (CTM); Phase 1; Service description".3Definitions, symbols and abbreviations3.1DefinitionsFor the purposes of the present document, the following definitions in addition to all terms defined in EN 300 444 [6]apply.supplementary service: service that modifies or supplements a basic telecommunications serviceteleservice: type of telecommunications service that provides the complete capability, including terminal equipmentfunctions, for communication between users, according to protocols that are established by agreement3.2SymbolsFor the purposes of the present document, the following symbols apply:NOTE 1:The symbols defined in this subclause are applied for procedures, features, services in the presentdocument if not explicitly otherwise stated. The interpretation of status columns in all tables is as follows:Mfor mandatory to support (provision mandatory, process mandatory);Ofor optional to support (provision optional, process mandatory);Ifor out-of-scope (provision optional, process optional) not subject for testing;Cfor conditional to support (process mandatory);N/Afor not-applicable (in the given context the specification makes it impossible to use this capability).Provision mandatory, process mandatory means that the indicated feature, service or procedure shall be implemented asdescribed in the present document, and may be subject to testing.SIST EN 301 361-1:2000

ETSIETSI EN 301 361-1 V1.1.1 (1999-10)8Provision optional, process mandatory means that the indicated feature, service or procedure may be implemented, andif implemented, the feature, service or procedure shall be implemented as described in the present document, and maybe subject to testing.NOTE 2:The used notation is based on the notation proposed in ISO/IEC 9646-7 [9].3.3AbbreviationsFor the purposes of the present document, the following abbreviations in addition to all abbreviations defined inEN 300 444 [6] apply:BRABasic Rate AccessCICommon InterfaceCLIPCalling Line Identification PresentationIAPISDN Access Profile [12]IEInformation ElementNCICNetwork Call-Independent ConnectionNCICsNetwork Call-Independent Connection Oriented SignallingNTNetwork TerminationPRAPrimary Rate AccessROSERemote Operation Service Element4Feature definitionsFor the purposes of the present document, the feature definitions in the following subclauses apply.The number given in parentheses after the name of a feature is the item number used in the tables of the presentdocument.4.1Network (NWK) featuresSee EN 300 444 [6].4.1.1Application featuresThe application features defined in the present document concern the interworking of the corresponding network layerfeatures. Hence no new definitions are required.5General requirements5.1Architecture5.1.1Reference configurationReference configurations describe functional groupings by using reference points, as described inITU Recommendation I.411 [13] for ISDN. For CTM, the reference configurations are shown in the alpha interfacespecification [8].An overview of standard ISDN and CTM specific reference configurations is shown in the following figure.SIST EN 301 361-1:2000

ETSIETSI EN 301 361-1 V1.1.1 (1999-10)9Figure 1: Standard ISDN and CTM specific reference configurationsThe present document is applicable for the Fixed Parts attached to the alpha reference point. The interface protocols forthe alpha interface are based upon the protocols defined for the T or the coincident S and T reference points.5.1.2InterfacesThis interworking profile is based on the alpha interface standard, which applies to public CTM networks.NOTE:The beta interface standard, which applies to private CTM networks, is not considered.The present document covers both basic rate and primary rate access (BRA, PRA). Point-to-multipoint as well as pointto point configurations are applicable.5.2Protocol modelThe following figure provides an overview of the protocol model used to describe the protocol interworking within theFT. The present document is mainly concerned with the interworking between DECT mobility management procedures(invoked by means of messages and information elements at the air interface) and the CTM mobility managementprocedures on the alpha interface (invoked by means of Remote Operations).Figure 2: Protocol model
R
S
T
U
S/T
U
aMM componentsMM messagesDECT CIISDN BRA/ PRATE2TATE1NT2PPNT1NT1FPPublicISDNISDN L2DECT PHLDECT MACDECT DLCISDN L1ISDN L3NCICsCCDECT NWKMMCCROSEFP-IWFPublicISDNPublicISDNSIST EN 301 361-1:2000

ETSIETSI EN 301 361-1 V1.1.1 (1999-10)10Table 1: Description of DECT and ISDN layersLayersDECTISDNL4 to 6EN 301 144-1 (CTM signalling application) [8]CCITT Recommendation X.219 (ROSE) [10]L3EN 300 175-5 (NWK) [5]EN 300 403-1 (CC) [7]EN 301 061-1 (NCICs) [11]L2EN 300 175-4 (DLC) [4]EN 300 175-3 (MAC) [3]ETS 300 402-1 [14]L1EN 300 175-2 [2]ETS 300 011-1 (PRA) [15]ETS 300 012-1 (BRA) [16]5.3Identity usage5.3.1CTM identityAt the alpha interface, the CTM identity is used to uniquely identify a CTM user. At the air interface however, theDECT PP- identity is used to identify the user. The FT provides the mapping between the PP- identity and theCTM- Identity.The present document assumes the following:-there is a one to one relation between the CTM identity and the PP- identity (IPUI);-there are no restrictions concerning the PP- identity to be used at the air interface.NOTE 1:The FT need not reject a PP- initiated request containing an identity type or length that may not besupported by the CTM network.NOTE 2:The use of non-CTM identities (e.g. residential identities) for roaming to/from the residential area isoutside the scope of the present document.5.3.2CTM numberThe CTM number is the E.164 number that is dialled to call a CTM user.In case CLIP is subscribed to, the network may provide the CTM number within the <> to thecalled user (public ISDN ® FP).5.3.3FP- addressThe FP- address is a globally unique E.164 number and corresponds to the address of the FT via which the PT isconnected to the ISDN access. The FP address is required only in case of a point to multipoint configuration.In case of an incoming call, the FP- address is conveyed inside the <> (public ISDN -> FP). Incase of an outgoing call, the FP- address is transferred within a <> (FP -> public ISDN).6Interoperability requirements6.1GeneralIn order to achieve interoperability, this clause defines the status of features and the associated interworkingrequirements in a similar manner as done in EN 300 444 (GAP) [6].The interworking requirements specified in the present document concern the application layer and the network layer.SIST EN 301 361-1:2000

ETSIETSI EN 301 361-1 V1.1.1 (1999-10)11The application layer requirements are specified in the present document. The ISDN network layer requirements arefully specified in EN 301 144-1 [8]. For the DECT network layer, all FT requirements specified in EN 300 444 (GAP)[6] apply unless explicitly stated otherwise. This means that only additions/modifications to EN 300 444 (GAP) [6] areincluded in this clause.6.2DECT NWK featuresAll requirements specified in subclause 6.2 of EN 300 444 [6] apply with the following modifications:Table 2: NWK features statusFeature supportedStatusItem no.Name of featureGAP[6]Ref.FTRBPN.13Identification of portable4.1MMMN.26Authentication of network4.1MMMN.9Authentication of portable4.1MMMN.11Location registration4.1MMMN.18Subscription registration4.1OOON.12Key allocation4.1MMMN.17Network initiated ciphering4.1MMMNOTE 1:The above table indicates the status of feature from a CTM service perspective. Features that are required byGAP may not be required for supporting the CTM service, in which case the feature will be optional in theabove table.NOTE 2:The CTM service should be uniform across different application areas. As a result, the status of features isthe same in all environments.6.3Application featuresThis subclause concerns the FT's application layer which mainly handles the interworking between the DECT and thealpha interface protocols.Table 3: Application features statusFeature supportedStatusItem no.Name of featureGAP[6]Ref.FTRBPIMIP-A.1General4.1.1MMMIMIP-A.2Identification of portable4.1.1MMMIMIP-A.3Authentication of network4.1.1MMMIMIP-A.4Authentication of portable4.1.1MMMIMIP-A.5Location registration4.1.1MMMIMIP-A.6Location cancellation4.1.1MMMIMIP-A.7Location registration suggest4.1.1MMMIMIP-A.8Subscription registration4.1.1OOOIMIP-A.9Key allocation4.1.1MMMIMIP-A.10Subscription deregistration4.1.1OOOIMIP-A.11Network initiated ciphering4.1.1MMMIMIP-A.12Portable initiated ciphering4.1.1OOOIMIP-A.13Outgoing call4.1.1MMMIMIP-A.14Incoming call4.1.1MMMIMIP-A.15Supplementary service activation4.1.1OOOIMIP-A.16DTMF generation4.1.1OOOSIST EN 301 361-1:2000

ETSIETSI EN 301 361-1 V1.1.1 (1999-10)126.4NWK feature to procedure mappingAll requirements specified in EN 300 444 [6] apply with the following modifications:Table 4: NWK feature to procedure mappingFeature/Procedure mappingStatusFeatureProcedureGAP[6]Ref.PTFTRBPLocation registrationMMMLocation update8.29MMMOutgoing callMMMOverlap sending8.3MMMOutgoing call proceeding8.4MMMOutgoing call confirmation8.5MMMFlexible U-plane connectionOOONOTE:For the listed features, only those procedures are specified for which the requirements are different ascompared to EN 300 444 (GAP) [6]; for feature location registration, the requirements for the locationregistration procedure are as specified in EN 300 444 (GAP) [6].SIST EN 301 361-1:2000

ETSIETSI EN 301 361-1 V1.1.1 (1999-10)136.5Application feature to procedure mappingThe references in the following table are to the present document.Table 5: Application feature to procedure mappingFeature/Procedure mappingStatusFeatureProcedureRef.FTRBPGeneralMMMConnection establishment andrelease7.1MMMGeneric mobility managementinterworking procedures7.2 to 7.2.4MMMGeneric message mapping8 to 8.2.2MMMGeneric information element8.4MMMIdentification of portableOOOIdentification of PP7.2.5MMMAuthentication of networkMMMAuthentication of network7.2.6MMMAuthentication of portableMMMAuthentication of PT7.2.7MMMLocation registrationMMMLocation registration7.2.8MMMLocation cancellationMMMLocation cancellation7.3.1MMMLocation registration suggestMMMLocation update7.2.9MMMSubscription registrationOOOObtaining access rights7.2.10MMMKey allocationMMMOn air key allocation7.2.11MMMSubscription deregistrationOOOFP terminating access rights7.2.12MMMNetwork initiated cipheringMMMCipher switching initiated by network7.2.13MMMPortable initiated cipheringOOOCipher switching initiated by PT7.2.14MMMOutgoing callMMMOutgoing call7.3.2MMMCall progress information transfer7.3.4OOOCall release7.3.5MMMIncoming callMMMIncoming call7.3.3MMMCall progress information transfer7.3.4OOOCall release7.3.5MMMSupplementary service activationOOOKeypad information transfer7.3.6MMMDTMF generationOOOKeypad information transfer7.3.6MMMNOTE:In order to simplify the specification, a feature "General" has been introduced. This is used to specify thestatus of clauses specifying interworking requirements/principles that are not related to a specific feature.SIST EN 301 361-1:2000

ETSIETSI EN 301 361-1 V1.1.1 (1999-10)147Procedure descriptionsThis clause specifies the interworking requirements for the mobility management procedures as required for CTMphase 1. Furthermore, this clause specifies additions/modifications to the interworking requirements for call control asspecified in the ISDN Access Profile [12].NOTE:The interworking requirements may include requirements concerning the interaction between interworkingand non-interworking procedures.The references in the tables of clause 7 are to the present document unless otherwise specified.7.1Connection establishment and releaseThis subclause describes the co-ordination between the radio connection establishment/release and theestablishment/release of the mobility management transport mechanism used at the alpha interface.There are requirements concerning co-ordination during connection establishment, but not for connection release.7.1.1NCICs connection controlThe NCICs connection establishment and release procedures are described in EN 301 144-1 [8]. The radio linkestablishment and release procedures are specified in subclauses 8.35 to 8.39 of EN 300 444 [6].There is co-ordination between NCICs and radio link control procedures during connection establishment and datatransfer, as specified in the following.7.1.2Connection establishment co-ordination7.1.2.1PT initiated mobility management transactionIn case the FT receives a PT- initiated mobility management request concerning a PT for which an NCICs connectionalready exists, it shall use this connection to transfer the mobility management request.In case the FT receives a PT- initiated mobility management request concerning a PT for which no NCICs connectionexists, the FT shall initiate the establishment of such a NCICS connection.NOTE:Across the alpha interface the NCICs connection establishment request shall include a CTM Identity. Incase the PT- initiated transaction request does not include a <>, the FT may need to deriveor retrieve the IPUI.SIST EN 301 361-1:2000

ETSIETSI EN 301 361-1 V1.1.1 (1999-10)15FPPPNTCALL_PROCEEDING<>CONNECTLOCATE-REQUEST<><><><>SETUP<><>
(InvokeRequest)
(LocationRegistration)



FACILITYLOCATE-ACCEPTP_MM_locate.1CONNECT_ACK<>
(ReturnResult)
(LocationRegistration)
F_T303F_T310<><>NOTE:This is the normal terminal initiated NCICs connection establishment. The Location Registration operationis given as an example.Figure 3: NCIC terminal initiated connection establishment7.1.2.2Network initiated mobility management transactionThe FT need not delay acceptance of the NCICs- connection establishment request until radio connection establishmenthas been completed successfully and/or a response has been received from the PT for the associated MM- transaction.The FT shall not reject an NCICs connection establishment request concerning a PT for which another NCICsconnection has already been established.NOTE:Although in most cases the network re- uses an existing NCICs connection for the concerned PT, this maynot always be possible. In the latter case, multiple simultaneous NCICs connections may be used for a PT.SIST EN 301 361-1:2000

ETSIETSI EN 301 361-1 V1.1.1 (1999-10)16FPSETUPPPNT<><><>
(InvokeRequest)
(IdentityRequest)

LCE-PAGE-REQUEST<><>CALL_PROCEEDINGLCE-PAGE-RESPONSECONNECTFACILITYCONNECT_ACKIDENTITY-REQUESTF_LCE.03N_T303N_T310<><><>F_MM_ident.2IDENTITY-REPLY<><>
(ReturnResult)
(IdentityRequest)
NOTE:This is the normal network initiated NCICs connection establishment. IdentifyRequest operation is givenas an example.Figure 4: NCIC network initiated connection establishment7.1.3Connection oriented data transfer co-ordinationIn case more than one NCICs connection exists for the connected PT, the FT shall apply the following rules:-a return result/error shall be transferred across the same NCICs connection as used to transfer the invoke;-a request concerning an embedded procedure, e.g. authentication of network, shall be returned across the sameNCICs connection as used to transfer the initial request that triggered the embedded procedure (e.g. terminateaccess rights, network initiated).NOTE:Within the CTM network, more than one node may initiate mobility management transactions. Due to this,the CTM network may be unable to ensure that only one NCICs connection is established per PT.SIST EN 301 361-1:2000

ETSIETSI EN 301 361-1 V1.1.1 (1999-10)177.1.4Connection release co-ordinationThe FT need not co-ordinate release of the radio link connection and the NCICs connection as illustrated in thefollowing sequence diagrams.FPPPNTRELEASE<>IDENTITY-REPLY<>FACILITY<>
(ReturnResult)
(IdentityRequest)
P_LCE.02RELEASE_COMPLETEMAC-RELEASEL_T308NOTE:Identity request is given as an example. Partial release applies at the air interface.Figure 5: NCIC network initiated call releaseFPPPNTFACILITY<>
(ReturnResult)
(LocationRegistration)
RELEASE<>F_T308RELEASE_COMPLETENOTE:Terminal initiated MM- signalling connection release. Only used in exceptional cases e.g. maintenanceaction.Figure 6: NCIC terminal initiated call releaseSIST EN 301 361-1:2000

ETSIETSI EN 301 361-1 V1.1.1 (1999-10)187.2Mobility management proceduresThe following table provides an overview of the mobility management procedures and their status in CTM phase 1 asspecified in EN 301 144-1 [8].Table 6: Overview of the mobility management proceduresProcedureDECT messagesMM operationNoteIdentification of PPIDENTITY-REQUESTIDENTITY-REPLYidentityRequestAuthentication of networkAUTHENTICATION-REQUESTAUTHENTICATION-REPLYAUTHENTICATION-REJECTnetworkAuthenticationAuthentication of PPAUTHENTICATION- REQUESTAUTHENTICATION-REPLYAUTHENTICATION-REJECTterminalAuthenticationLocation registrationLOCATE-REQUESTLOCATE-ACCEPTLOCATE-REJECTTEMPORARY-IDENTITY-ASSIGN-ACKTEMPORARY-IDENTITY-ASSIGN-REJECTlocationRegistration1Location updateMM-INFO-SUGGESTlocationRegistrationSuggest2Obtaining access rightsACCESS-RIGHTS-REQUESTACCESS-RIGHTS-ACCEPTACCESS-RIGHTS-REJECTaccessRightsRequestNetwork terminating accessrightsACCESS-RIGHTS-TERMINATE-REQUESTACCESS-RIGHTS- TERMINATE-ACCEPTACCESS-RIGHTS- TERMINATE-REJECTaccessRightsTerminateOn air key allocationKEY-ALLOCATEAUTHENTICATION-REQUESTAUTHENTICATION-REPLYAUTHENTICATION-REJECTkeyAllocate, networkAuthenticationCipher switching initiated bynetworkCIPHER-REQUESTCIPHER-REJECT(DL_ENCRYPT.IND)ciphering3Cipher switching initiated byPPCIPHER-SUGGESTcipheringSuggest4NOTE 1:This procedure includes an additional information transfer related to the assignment of a temporary identity.NOTE 2:This procedure applies two subsequent transactions.NOTE 3:For this procedure the return result is triggered by a local primitive rather than by a network layer messagereceived across air interface.NOTE 4:At the air interface, the PT initiated ciphering and the subsequent network initiated ciphering are consider as asingle transaction.The following sublauses only describe the generic interworking procedures. Additional requirements, if applicable, areincluded in the sublause providing the interworking procedure specific for the corresponding MM- procedure.The feature specific sublauses also include message interworking specifications, for which the general principles aredescribed in subclause 8.1.7.2.1Generic interworking procedures, network initiated transaction,explicit acknowledgement7.2.1.1FT accepts mobility management requestUpon reception of a MM invoke component concerning a network initiated mobility management request, the FT shallinitiate the corresponding mobility management transaction towards the PT. This involves the starting of the relatedFP- timer as described in EN 300 175-5 [5] and the interworking of the MM component as specified within theapplicable feature specific procedure description.SIST EN 301 361-1:2000

ETSIETSI EN 301 361-1 V1.1.1 (1999-10)197.2.1.2FT receives response from PTUpon reception of the response, either positive or negative, the FP shall stop the applicable timer as described inEN 300 175-5 [5] and interwork the received DECT message to the corresponding MM return result or return errorcomponent.7.2.1.3FT rejects mobility management requestIn case the FT rejects the network initiated mobility management request, it shall send a MM return error componenttowards the network, including an error value indicating the reason of rejection.NOTE:The FT may reject the network initiated mobility management request in case of resource contention, noresponse to paging, expiry of the applicable DECT timer, loss of the radio link connection.FPPPNTFACILITY<>
(InvokeRequest)
(TerminalAuthentication)


<>
(ReturnResult)
(TerminalAuthentication)

FACILITYAUTHENTICATION-REPLYF_MM_auth.1<>
<>
<>AUTHENTICATION-REQUEST<><>NOTE:Terminal authentication is shown as an example. FACILITY is shown as a possible NCICs data transportmessage.Figure 7: Network initiated MM transaction with ex
...


2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.Digital Enhanced Cordless Telecommunications (DECT); Integrated Services Digital Network (ISDN); ISDN Mobility protocol Interworking specification Profile (IMIP); Part 1: DECT/ISDN interworking for Cordless Terminal Mobility (CTM) support33.080Digitalno omrežje z integriranimi storitvami (ISDN)Integrated Services Digital Network (ISDN)33.070.30'(&7Digital Enhanced Cordless Telecommunications (DECT)ICS:Ta slovenski standard je istoveten z:EN 301 361-1 Version 1.1.1SIST EN 301 361-1:2000en01-julij-2000SIST EN 301 361-1:2000SLOVENSKI
STANDARD
ETSIETSI EN 301 361-1 V1.1.1 (1999-10)2ReferenceDEN/DECT-030126 (clo90ico.PDF)KeywordsCTM, DECT, DSS1+, interworking, ISDN, mobilityETSIPostal addressF-06921 Sophia Antipolis Cedex - FRANCEOffice address650 Route des Lucioles - Sophia AntipolisValbonne - FRANCETel.: +33 4 92 94 42 00
Fax: +33 4 93 65 47 16Siret N° 348 623 562 00017 - NAF 742 CAssociation à but non lucratif enregistrée à laSous-Préfecture de Grasse (06) N° 7803/88Internetsecretariat@etsi.frIndividual copies of this ETSI deliverablecan be downloaded fromhttp://www.etsi.orgIf you find errors in the present document, send yourcomment to: editor@etsi.frCopyright NotificationNo part may be reproduced except as authorized by written permission.The copyright and the foregoing restriction extend to reproduction in all media.© European Telecommunications Standards Institute 1999.All rights reserved.SIST EN 301 361-1:2000

ETSIETSI EN 301 361-1 V1.1.1 (1999-10)3ContentsIntellectual Property Rights.5Foreword.5Introduction.51Scope.62References.63Definitions, symbols and abbreviations.73.1Definitions.73.2Symbols.73.3Abbreviations.84Feature definitions.84.1Network (NWK) features.84.1.1Application features.85General requirements.85.1Architecture.85.1.1Reference configuration.85.1.2Interfaces.95.2Protocol model.95.3Identity usage.105.3.1CTM identity.105.3.2CTM number.105.3.3FP- address.106Interoperability requirements.106.1General.106.2DECT NWK features.116.3Application features.116.4NWK feature to procedure mapping.126.5Application feature to procedure mapping.137Procedure descriptions.147.1Connection establishment and release.147.1.1NCICs connection control.147.1.2Connection establishment co-ordination.147.1.2.1PT initiated mobility management transaction.147.1.2.2Network initiated mobility management transaction.157.1.3Connection oriented data transfer co-ordination.167.1.4Connection release co-ordination.177.2Mobility management procedures.187.2.1Generic interworking procedures, network initiated transaction, explicit acknowledgement.187.2.1.1FT accepts mobility management request.187.2.1.2FT receives response from PT.197.2.1.3FT rejects mobility management request.197.2.2Generic interworking procedures, network initiated transaction, no explicit acknowledgement.197.2.2.1FT accepts mobility management request.197.2.2.2FT rejects mobility management request.207.2.3Generic interworking procedures, PT initiated transaction, explicit acknowledgement.207.2.3.1FT accepts mobility management request.207.2.3.2FT receives response from network.207.2.3.3FT rejects mobility management request.207.2.4Generic interworking procedures, PT initiated transaction with no explicit acknowledgement.217.2.4.1FT accepts mobility management request.217.2.4.2FT rejects mobility management request.217.2.5Identification of PT.22SIST EN 301 361-1:2000

ETSIETSI EN 301 361-1 V1.1.1 (1999-10)47.2.6Authentication of network.237.2.7Authentication of PT.247.2.8Location registration.257.2.8.1FT initiates temporary identity assignment.257.2.8.2FT receives temporary reject from network.267.2.9Location update.267.2.10Obtaining access rights.267.2.11On air key allocation.277.2.11.1FT accepts or rejects mobility management request.277.2.11.2FT receives positive response from PT.287.2.11.3FT receives negative response from PT.287.2.11.4FT receives authentication response from network.297.2.12FT terminating access rights.297.2.13Network initiated ciphering.297.2.14Portable initiated ciphering.307.3Call control procedures.317.3.1General.317.3.2Outgoing call.317.3.3Incoming call.347.3.4Call progress information transfer.387.3.5Call release.387.3.5.1Network initiated release.397.3.5.2PT initiated release.407.3.5.3Other release cases.407.3.6Keypad information transfer.417.4Other interworking procedures.417.4.1Interaction in-between MM transactions.417.4.2Interactions between MM- and CC- transactions.417.4.3Other interactions between local and interworked procedures.427.4.4Error handling.428Message mappings.428.1General.428.2Mobility management message/component mapping.438.2.1MM component to DECT message.438.2.2DECT message to MM component.438.3Call control message mapping.448.3.1DSS1 message to DECT message.448.3.2DECT message to DSS1 message.448.4Information element/parameter mapping.458.4.1CTM information element/parameter to DECT information element.458.4.1.1General/transparent mapping.458.4.1.2<_componentType>+ <_operation> - << message type>>.468.4.1.3<_cTMIdentityType> - <>.468.4.1.4<_invokeIdentifier> - << transaction identifier>>.478.4.2DECT information element to CTM information element/parameter.478.4.2.1General/transparent mapping.478.4.2.2Fixed identity + location area - _cTMOldLocationAreaIdentity.478.4.2.3Message type - _componentType+ _operation.488.4.2.4Transaction identifier - _invokeIdentifier.48Bibliography.49History.50SIST EN 301 361-1:2000

ETSIETSI EN 301 361-1 V1.1.1 (1999-10)5Intellectual Property RightsIPRs essential or potentially essential to the present document may have been declared to ETSI. The informationpertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be foundin SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respectof ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web server(http://www.etsi.org/ipr).Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guaranteecan be given as to the existence of other IPRs not referenced in SR 000 314 (or the updates on the ETSI Web server)which are, or may be, or may become, essential to the present document.ForewordThis European Standard (Telecommunications series) has been produced by ETSI Project Digital Enhanced CordlessTelecommunications (DECT).The present document is part 1 of a multi-part EN covering the ISDN Mobility protocol Interworking specificationProfile (IMIP), as identified below:Part 1:"DECT/ISDN interworking for Cordless Terminal Mobility (CTM) support";Part 2:"DECT/ISDN interworking for Global System for Mobile communications (GSM) support".National transposition datesDate of adoption of this EN:27 August 1999Date of latest announcement of the present document (doa):30 November 1999Date of latest publication of new National Standardor endorsement of the present document (dop/e):31 May 2000Date of withdrawal of any conflicting National Standard (dow):31 May 2000IntroductionThis two-part EN defines a profile for interworking between a DECT system and an Integrated Services Digital Network(ISDN) using the enhanced Digital Subscriber Signalling No. 1 (DSS1) protocol defined in EN 301 144-1 [8]. ThisISDN protocol enables cordless terminals to have access to an ISDN infrastructure.Part one defines the DECT/DSS1+ interworking for the CTM support.Part two considers the DECT/DSS1+ interworking for the GSM support.The present document specifies how DSS1+ procedures and information are mapped over the DECT air interface, andhow they are provided and used by the DECT Fixed Part.SIST EN 301 361-1:2000

ETSIETSI EN 301 361-1 V1.1.1 (1999-10)61ScopeThe present document specifies a set of technical requirements for Digital Enhanced Cordless Telecommunications(DECT) Fixed Parts (FP) supporting connection, via an ISDN interface, to a network supporting terminal mobility.The standard covers the requirements necessary for the support of Cordless Terminal Mobility (CTM) Phase 1 (Part 1)and for the support of the DECT access to GSM via ISDN interfaces (Part 2). In both of these scenarios, the FT isconnected to the network via the alpha interface, as specified in EN 301 144-1 [8].NOTE:For CTM phase 1, the Portable Part (PP) requirements are specified in EN 300 444 [6].The present document specifies the interworking procedures between the Digital Enhanced CordlessTelecommunications (DECT) air interface and the mobility management protocols defined for Integrated ServicesDigital Network (ISDN) interfaces.The ISDN Access Profile (IAP), ETS 300 434-2 [12], specifies the requirements for the support of ISDN services. Apartfrom the mobility management procedures, that are covered in the present document, the IAP includes interworkingspecifications for the support of basic call.2ReferencesThe following documents contain provisions which, through reference in this text, constitute provisions of the presentdocument.· References are either specific (identified by date of publication, edition number, version number, etc.) ornon-specific.· For a specific reference, subsequent revisions do not apply.· For a non-specific reference, the latest version applies.· A non-specific reference to an ETS shall also be taken to refer to later versions published as an EN with the samenumber.[1]EN 300 175-1: "Digital Enhanced Cordless Telecommunications (DECT); Common Interface (CI);Part 1: Overview".[2]EN 300 175-2: "Digital Enhanced Cordless Telecommunications (DECT); Common Interface (CI);Part 2: Physical Layer (PHL)".[3]EN 300 175-3: "Digital Enhanced Cordless Telecommunications (DECT); Common Interface (CI);Part 3: Medium Access Control (MAC) Layer".[4]EN 300 175-4: "Digital Enhanced Cordless Telecommunications (DECT); Common Interface (CI);Part 4: Data Link Control (DLC) Layer".[5]EN 300 175-5: "Digital Enhanced Cordless Telecommunications (DECT); Common Interface (CI);Part 5: Network (NWK) Layer".[6]EN 300 444: "Digital Enhanced Cordless Telecommunications (DECT); Generic Access Profile(GAP)".[7]EN 300 403-1: "Integrated Services Digital Network (ISDN); Digital Subscriber Signalling SystemNo. one (DSS1) protocol; Signalling network layer for circuit-mode basic call control;Part 1: Protocol specification [ITU-T Recommendation Q.931 (1993), modified]".[8]EN 301 144-1: "Integrated Services Digital Network (ISDN); Digital Subscriber Signalling SystemNo. one (DSS1) and Signalling System No.7 (SS7); Signalling application for the mobilitymanagement service on the alpha interface; Part 1: Protocol specification".SIST EN 301 361-1:2000

ETSIETSI EN 301 361-1 V1.1.1 (1999-10)7[9]ISO/IEC 9646-7 (1995): "Information technology - Open Systems Interconnection - Conformancetesting methodology and framework - Part 7: Implementation Conformance Statements".[10]CCITT Recommendation X.219 (1988): "Remote operation: Model, notation and servicedefinition".[11]EN 301 061-1 (1.2.2): "Integrated Services Digital Network (ISDN); Digital Subscriber SignallingSystem No. one (DSS1) protocol; Generic functional protocol for the support of supplementaryservices at the "b" service entry point for Virtual Private Network (VPN) applications; Part 1:Protocol specification".[12]ETS 300 434-2: "Digital Enhanced Cordless Telecommunications (DECT); Integrated ServicesDigital Network (ISDN); DECT/ISDN interworking for end system configuration; Part 2: Accessprofile".[13]CCITT Recommendation I.411 (1988): "ISDN user-network interfaces; Reference configurations".[14]ETS 300 402-1: "Integrated Services Digital Network (ISDN); Digital Subscriber SignallingSystem No. one (DSS1) protocol; Data link layer; Part 1: General aspects [ITU-TRecommendation Q.920 (1993), modified]".[15]ETS 300 011-1: "Integrated Services Digital Network (ISDN); Primary rate User-NetworkInterface (UNI); Part 1: Layer 1 specification".[16]ETS 300 012-1: "Integrated Services Digital Network (ISDN); Basic user-network interface;Layer 1 specification and test principles; Part 1: Layer 1 specification".[17]EN 301 175: "Cordless Terminal Mobility (CTM); Phase 1; Service description".3Definitions, symbols and abbreviations3.1DefinitionsFor the purposes of the present document, the following definitions in addition to all terms defined in EN 300 444 [6]apply.supplementary service: service that modifies or supplements a basic telecommunications serviceteleservice: type of telecommunications service that provides the complete capability, including terminal equipmentfunctions, for communication between users, according to protocols that are established by agreement3.2SymbolsFor the purposes of the present document, the following symbols apply:NOTE 1:The symbols defined in this subclause are applied for procedures, features, services in the presentdocument if not explicitly otherwise stated. The interpretation of status columns in all tables is as follows:Mfor mandatory to support (provision mandatory, process mandatory);Ofor optional to support (provision optional, process mandatory);Ifor out-of-scope (provision optional, process optional) not subject for testing;Cfor conditional to support (process mandatory);N/Afor not-applicable (in the given context the specification makes it impossible to use this capability).Provision mandatory, process mandatory means that the indicated feature, service or procedure shall be implemented asdescribed in the present document, and may be subject to testing.SIST EN 301 361-1:2000

ETSIETSI EN 301 361-1 V1.1.1 (1999-10)8Provision optional, process mandatory means that the indicated feature, service or procedure may be implemented, andif implemented, the feature, service or procedure shall be implemented as described in the present document, and maybe subject to testing.NOTE 2:The used notation is based on the notation proposed in ISO/IEC 9646-7 [9].3.3AbbreviationsFor the purposes of the present document, the following abbreviations in addition to all abbreviations defined inEN 300 444 [6] apply:BRABasic Rate AccessCICommon InterfaceCLIPCalling Line Identification PresentationIAPISDN Access Profile [12]IEInformation ElementNCICNetwork Call-Independent ConnectionNCICsNetwork Call-Independent Connection Oriented SignallingNTNetwork TerminationPRAPrimary Rate AccessROSERemote Operation Service Element4Feature definitionsFor the purposes of the present document, the feature definitions in the following subclauses apply.The number given in parentheses after the name of a feature is the item number used in the tables of the presentdocument.4.1Network (NWK) featuresSee EN 300 444 [6].4.1.1Application featuresThe application features defined in the present document concern the interworking of the corresponding network layerfeatures. Hence no new definitions are required.5General requirements5.1Architecture5.1.1Reference configurationReference configurations describe functional groupings by using reference points, as described inITU Recommendation I.411 [13] for ISDN. For CTM, the reference configurations are shown in the alpha interfacespecification [8].An overview of standard ISDN and CTM specific reference configurations is shown in the following figure.SIST EN 301 361-1:2000

ETSIETSI EN 301 361-1 V1.1.1 (1999-10)9Figure 1: Standard ISDN and CTM specific reference configurationsThe present document is applicable for the Fixed Parts attached to the alpha reference point. The interface protocols forthe alpha interface are based upon the protocols defined for the T or the coincident S and T reference points.5.1.2InterfacesThis interworking profile is based on the alpha interface standard, which applies to public CTM networks.NOTE:The beta interface standard, which applies to private CTM networks, is not considered.The present document covers both basic rate and primary rate access (BRA, PRA). Point-to-multipoint as well as pointto point configurations are applicable.5.2Protocol modelThe following figure provides an overview of the protocol model used to describe the protocol interworking within theFT. The present document is mainly concerned with the interworking between DECT mobility management procedures(invoked by means of messages and information elements at the air interface) and the CTM mobility managementprocedures on the alpha interface (invoked by means of Remote Operations).Figure 2: Protocol model
R
S
T
U
S/T
U
aMM componentsMM messagesDECT CIISDN BRA/ PRATE2TATE1NT2PPNT1NT1FPPublicISDNISDN L2DECT PHLDECT MACDECT DLCISDN L1ISDN L3NCICsCCDECT NWKMMCCROSEFP-IWFPublicISDNPublicISDNSIST EN 301 361-1:2000

ETSIETSI EN 301 361-1 V1.1.1 (1999-10)10Table 1: Description of DECT and ISDN layersLayersDECTISDNL4 to 6EN 301 144-1 (CTM signalling application) [8]CCITT Recommendation X.219 (ROSE) [10]L3EN 300 175-5 (NWK) [5]EN 300 403-1 (CC) [7]EN 301 061-1 (NCICs) [11]L2EN 300 175-4 (DLC) [4]EN 300 175-3 (MAC) [3]ETS 300 402-1 [14]L1EN 300 175-2 [2]ETS 300 011-1 (PRA) [15]ETS 300 012-1 (BRA) [16]5.3Identity usage5.3.1CTM identityAt the alpha interface, the CTM identity is used to uniquely identify a CTM user. At the air interface however, theDECT PP- identity is used to identify the user. The FT provides the mapping between the PP- identity and theCTM- Identity.The present document assumes the following:-there is a one to one relation between the CTM identity and the PP- identity (IPUI);-there are no restrictions concerning the PP- identity to be used at the air interface.NOTE 1:The FT need not reject a PP- initiated request containing an identity type or length that may not besupported by the CTM network.NOTE 2:The use of non-CTM identities (e.g. residential identities) for roaming to/from the residential area isoutside the scope of the present document.5.3.2CTM numberThe CTM number is the E.164 number that is dialled to call a CTM user.In case CLIP is subscribed to, the network may provide the CTM number within the <> to thecalled user (public ISDN ® FP).5.3.3FP- addressThe FP- address is a globally unique E.164 number and corresponds to the address of the FT via which the PT isconnected to the ISDN access. The FP address is required only in case of a point to multipoint configuration.In case of an incoming call, the FP- address is conveyed inside the <> (public ISDN -> FP). Incase of an outgoing call, the FP- address is transferred within a <> (FP -> public ISDN).6Interoperability requirements6.1GeneralIn order to achieve interoperability, this clause defines the status of features and the associated interworkingrequirements in a similar manner as done in EN 300 444 (GAP) [6].The interworking requirements specified in the present document concern the application layer and the network layer.SIST EN 301 361-1:2000

ETSIETSI EN 301 361-1 V1.1.1 (1999-10)11The application layer requirements are specified in the present document. The ISDN network layer requirements arefully specified in EN 301 144-1 [8]. For the DECT network layer, all FT requirements specified in EN 300 444 (GAP)[6] apply unless explicitly stated otherwise. This means that only additions/modifications to EN 300 444 (GAP) [6] areincluded in this clause.6.2DECT NWK featuresAll requirements specified in subclause 6.2 of EN 300 444 [6] apply with the following modifications:Table 2: NWK features statusFeature supportedStatusItem no.Name of featureGAP[6]Ref.FTRBPN.13Identification of portable4.1MMMN.26Authentication of network4.1MMMN.9Authentication of portable4.1MMMN.11Location registration4.1MMMN.18Subscription registration4.1OOON.12Key allocation4.1MMMN.17Network initiated ciphering4.1MMMNOTE 1:The above table indicates the status of feature from a CTM service perspective. Features that are required byGAP may not be required for supporting the CTM service, in which case the feature will be optional in theabove table.NOTE 2:The CTM service should be uniform across different application areas. As a result, the status of features isthe same in all environments.6.3Application featuresThis subclause concerns the FT's application layer which mainly handles the interworking between the DECT and thealpha interface protocols.Table 3: Application features statusFeature supportedStatusItem no.Name of featureGAP[6]Ref.FTRBPIMIP-A.1General4.1.1MMMIMIP-A.2Identification of portable4.1.1MMMIMIP-A.3Authentication of network4.1.1MMMIMIP-A.4Authentication of portable4.1.1MMMIMIP-A.5Location registration4.1.1MMMIMIP-A.6Location cancellation4.1.1MMMIMIP-A.7Location registration suggest4.1.1MMMIMIP-A.8Subscription registration4.1.1OOOIMIP-A.9Key allocation4.1.1MMMIMIP-A.10Subscription deregistration4.1.1OOOIMIP-A.11Network initiated ciphering4.1.1MMMIMIP-A.12Portable initiated ciphering4.1.1OOOIMIP-A.13Outgoing call4.1.1MMMIMIP-A.14Incoming call4.1.1MMMIMIP-A.15Supplementary service activation4.1.1OOOIMIP-A.16DTMF generation4.1.1OOOSIST EN 301 361-1:2000

ETSIETSI EN 301 361-1 V1.1.1 (1999-10)126.4NWK feature to procedure mappingAll requirements specified in EN 300 444 [6] apply with the following modifications:Table 4: NWK feature to procedure mappingFeature/Procedure mappingStatusFeatureProcedureGAP[6]Ref.PTFTRBPLocation registrationMMMLocation update8.29MMMOutgoing callMMMOverlap sending8.3MMMOutgoing call proceeding8.4MMMOutgoing call confirmation8.5MMMFlexible U-plane connectionOOONOTE:For the listed features, only those procedures are specified for which the requirements are different ascompared to EN 300 444 (GAP) [6]; for feature location registration, the requirements for the locationregistration procedure are as specified in EN 300 444 (GAP) [6].SIST EN 301 361-1:2000

ETSIETSI EN 301 361-1 V1.1.1 (1999-10)136.5Application feature to procedure mappingThe references in the following table are to the present document.Table 5: Application feature to procedure mappingFeature/Procedure mappingStatusFeatureProcedureRef.FTRBPGeneralMMMConnection establishment andrelease7.1MMMGeneric mobility managementinterworking procedures7.2 to 7.2.4MMMGeneric message mapping8 to 8.2.2MMMGeneric information element8.4MMMIdentification of portableOOOIdentification of PP7.2.5MMMAuthentication of networkMMMAuthentication of network7.2.6MMMAuthentication of portableMMMAuthentication of PT7.2.7MMMLocation registrationMMMLocation registration7.2.8MMMLocation cancellationMMMLocation cancellation7.3.1MMMLocation registration suggestMMMLocation update7.2.9MMMSubscription registrationOOOObtaining access rights7.2.10MMMKey allocationMMMOn air key allocation7.2.11MMMSubscription deregistrationOOOFP terminating access rights7.2.12MMMNetwork initiated cipheringMMMCipher switching initiated by network7.2.13MMMPortable initiated cipheringOOOCipher switching initiated by PT7.2.14MMMOutgoing callMMMOutgoing call7.3.2MMMCall progress information transfer7.3.4OOOCall release7.3.5MMMIncoming callMMMIncoming call7.3.3MMMCall progress information transfer7.3.4OOOCall release7.3.5MMMSupplementary service activationOOOKeypad information transfer7.3.6MMMDTMF generationOOOKeypad information transfer7.3.6MMMNOTE:In order to simplify the specification, a feature "General" has been introduced. This is used to specify thestatus of clauses specifying interworking requirements/principles that are not related to a specific feature.SIST EN 301 361-1:2000

ETSIETSI EN 301 361-1 V1.1.1 (1999-10)147Procedure descriptionsThis clause specifies the interworking requirements for the mobility management procedures as required for CTMphase 1. Furthermore, this clause specifies additions/modifications to the interworking requirements for call control asspecified in the ISDN Access Profile [12].NOTE:The interworking requirements may include requirements concerning the interaction between interworkingand non-interworking procedures.The references in the tables of clause 7 are to the present document unless otherwise specified.7.1Connection establishment and releaseThis subclause describes the co-ordination between the radio connection establishment/release and theestablishment/release of the mobility management transport mechanism used at the alpha interface.There are requirements concerning co-ordination during connection establishment, but not for connection release.7.1.1NCICs connection controlThe NCICs connection establishment and release procedures are described in EN 301 144-1 [8]. The radio linkestablishment and release procedures are specified in subclauses 8.35 to 8.39 of EN 300 444 [6].There is co-ordination between NCICs and radio link control procedures during connection establishment and datatransfer, as specified in the following.7.1.2Connection establishment co-ordination7.1.2.1PT initiated mobility management transactionIn case the FT receives a PT- initiated mobility management request concerning a PT for which an NCICs connectionalready exists, it shall use this connection to transfer the mobility management request.In case the FT receives a PT- initiated mobility management request concerning a PT for which no NCICs connectionexists, the FT shall initiate the establishment of such a NCICS connection.NOTE:Across the alpha interface the NCICs connection establishment request shall include a CTM Identity. Incase the PT- initiated transaction request does not include a <>, the FT may need to deriveor retrieve the IPUI.SIST EN 301 361-1:2000

ETSIETSI EN 301 361-1 V1.1.1 (1999-10)15FPPPNTCALL_PROCEEDING<>CONNECTLOCATE-REQUEST<><><><>SETUP<><>
(InvokeRequest)
(LocationRegistration)



FACILITYLOCATE-ACCEPTP_MM_locate.1CONNECT_ACK<>
(ReturnResult)
(LocationRegistration)
F_T303F_T310<><>NOTE:This is the normal terminal initiated NCICs connection establishment. The Location Registration operationis given as an example.Figure 3: NCIC terminal initiated connection establishment7.1.2.2Network initiated mobility management transactionThe FT need not delay acceptance of the NCICs- connection establishment request until radio connection establishmenthas been completed successfully and/or a response has been received from the PT for the associated MM- transaction.The FT shall not reject an NCICs connection establishment request concerning a PT for which another NCICsconnection has already been established.NOTE:Although in most cases the network re- uses an existing NCICs connection for the concerned PT, this maynot always be possible. In the latter case, multiple simultaneous NCICs connections may be used for a PT.SIST EN 301 361-1:2000

ETSIETSI EN 301 361-1 V1.1.1 (1999-10)16FPSETUPPPNT<><><>
(InvokeRequest)
(IdentityRequest)

LCE-PAGE-REQUEST<><>CALL_PROCEEDINGLCE-PAGE-RESPONSECONNECTFACILITYCONNECT_ACKIDENTITY-REQUESTF_LCE.03N_T303N_T310<><><>F_MM_ident.2IDENTITY-REPLY<><>
(ReturnResult)
(IdentityRequest)
NOTE:This is the normal network initiated NCICs connection establishment. IdentifyRequest operation is givenas an example.Figure 4: NCIC network initiated connection establishment7.1.3Connection oriented data transfer co-ordinationIn case more than one NCICs connection exists for the connected PT, the FT shall apply the following rules:-a return result/error shall be transferred across the same NCICs connection as used to transfer the invoke;-a request concerning an embedded procedure, e.g. authentication of network, shall be returned across the sameNCICs connection as used to transfer the initial request that triggered the embedded procedure (e.g. terminateaccess rights, network initiated).NOTE:Within the CTM network, more than one node may initiate mobility management transactions. Due to this,the CTM network may be unable to ensure that only one NCICs connection is established per PT.SIST EN 301 361-1:2000

ETSIETSI EN 301 361-1 V1.1.1 (1999-10)177.1.4Connection release co-ordinationThe FT need not co-ordinate release of the radio link connection and the NCICs connection as illustrated in thefollowing sequence diagrams.FPPPNTRELEASE<>IDENTITY-REPLY<>FACILITY<>
(ReturnResult)
(IdentityRequest)
P_LCE.02RELEASE_COMPLETEMAC-RELEASEL_T308NOTE:Identity request is given as an example. Partial release applies at the air interface.Figure 5: NCIC network initiated call releaseFPPPNTFACILITY<>
(ReturnResult)
(LocationRegistration)
RELEASE<>F_T308RELEASE_COMPLETENOTE:Terminal initiated MM- signalling connection release. Only used in exceptional cases e.g. maintenanceaction.Figure 6: NCIC terminal initiated call releaseSIST EN 301 361-1:2000

ETSIETSI EN 301 361-1 V1.1.1 (1999-10)187.2Mobility management proceduresThe following table provides an overview of the mobility management procedures and their status in CTM phase 1 asspecified in EN 301 144-1 [8].Table 6: Overview of the mobility management proceduresProcedureDECT messagesMM operationNoteIdentification of PPIDENTITY-REQUESTIDENTITY-REPLYidentityRequestAuthentication of networkAUTHENTICATION-REQUESTAUTHENTICATION-REPLYAUTHENTICATION-REJECTnetworkAuthenticationAuthentication of PPAUTHENTICATION- REQUESTAUTHENTICATION-REPLYAUTHENTICATION-REJECTterminalAuthenticationLocation registrationLOCATE-REQUESTLOCATE-ACCEPTLOCATE-REJECTTEMPORARY-IDENTITY-ASSIGN-ACKTEMPORARY-IDENTITY-ASSIGN-REJECTlocationRegistration1Location updateMM-INFO-SUGGESTlocationRegistrationSuggest2Obtaining access rightsACCESS-RIGHTS-REQUESTACCESS-RIGHTS-ACCEPTACCESS-RIGHTS-REJECTaccessRightsRequestNetwork terminating accessrightsACCESS-RIGHTS-TERMINATE-REQUESTACCESS-RIGHTS- TERMINATE-ACCEPTACCESS-RIGHTS- TERMINATE-REJECTaccessRightsTerminateOn air key allocationKEY-ALLOCATEAUTHENTICATION-REQUESTAUTHENTICATION-REPLYAUTHENTICATION-REJECTkeyAllocate, networkAuthenticationCipher switching initiated bynetworkCIPHER-REQUESTCIPHER-REJECT(DL_ENCRYPT.IND)ciphering3Cipher switching initiated byPPCIPHER-SUGGESTcipheringSuggest4NOTE 1:This procedure includes an additional information transfer related to the assignment of a temporary identity.NOTE 2:This procedure applies two subsequent transactions.NOTE 3:For this procedure the return result is triggered by a local primitive rather than by a network layer messagereceived across air interface.NOTE 4:At the air interface, the PT initiated ciphering and the subsequent network initiated ciphering are consider as asingle transaction.The following sublauses only describe the generic interworking procedures. Additional requirements, if applicable, areincluded in the sublause providing the interworking procedure specific for the corresponding MM- procedure.The feature specific sublauses also include message interworking specifications, for which the general principles aredescribed in subclause 8.1.7.2.1Generic interworking procedures, network initiated transaction,explicit acknowledgement7.2.1.1FT accepts mobility management requestUpon reception of a MM invoke component concerning a network initiated mobility management request, the FT shallinitiate the corresponding mobility management transaction towards the PT. This involves the starting of the relatedFP- timer as described in EN 300 175-5 [5] and the interworking of the MM component as specified within theapplicable feature specific procedure description.SIST EN 301 361-1:2000

ETSIETSI EN 301 361-1 V1.1.1 (1999-10)197.2.1.2FT receives response from PTUpon reception of the response, either positive or negative, the FP shall stop the applicable timer as described inEN 300 175-5 [5] and interwork the received DECT message to the corresponding MM return result or return errorcomponent.7.2.1.3FT rejects mobility management requestIn case the FT rejects the network initiated mobility management request, it shall send a MM return error componenttowards the network, including an error value indicating the reason of rejection.NOTE:The FT may reject the network initiated mobility management request in case of resource contention, noresponse to paging, expiry of the applicable DECT timer, loss of the radio link connection.FPPPNTFACILITY<>
(InvokeRequest)
(TerminalAuthentication)


<>
(ReturnResult)
(TerminalAuthentication)

FACILITYAUTHENTICATION-REPLYF_MM_auth.1<>
<>
<>AUTHENTICATION-REQUEST<><>NOTE:Terminal authentication is shown as an example. FACILITY is shown as a possible NCICs data transportmessage.Figure 7: Network initiated MM transaction
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.

Loading comments...