TIA-136-337-2000 TDMA- Third Generation Wireless-Packet Data Service- Tunneling of Signaling Messages (ANSI APPROVAL WITHDRAWN JUNE 12 2015).pdf

《TIA-136-337-2000 TDMA- Third Generation Wireless-Packet Data Service- Tunneling of Signaling Messages (ANSI APPROVAL WITHDRAWN JUNE 12 2015).pdf》由会员分享，可在线阅读，更多相关《TIA-136-337-2000 TDMA- Third Generation Wireless-Packet Data Service- Tunneling of Signaling Messages (ANSI APPROVAL WITHDRAWN JUNE 12 2015).pdf（22页珍藏版）》请在麦多课文档分享上搜索。

1、 ANSI/TIA-136-337-2000 APPROVED: MARCH 31, 2000 REAFFIRMED: OCTOBER 20, 2004 REAFFIRMED: AUGUST 14, 2013 WITHDRAWN: JUNE 12, 2015 TIA-136-337 March 2000TDMA Third Generation Wireless- Packet Data Service- Tunneling of Signaling Messages NOTICE TIA Engineering Standards and Publications are designed

2、to serve the public interest through eliminating misunderstandings between manufacturers and purchasers, facilitating interchangeability and improvement of products, and assisting the purchaser in selecting and obtaining with minimum delay the proper product for their particular need. The existence

3、of such Standards and Publications shall not in any respect preclude any member or non-member of TIA from manufacturing or selling products not conforming to such Standards and Publications. Neither shall the existence of such Standards and Publications preclude their voluntary use by Non-TIA member

4、s, either domestically or internationally. Standards and Publications are adopted by TIA in accordance with the American National Standards Institute (ANSI) patent policy. By such action, TIA does not assume any liability to any patent owner, nor does it assume any obligation whatever to parties ado

5、pting the Standard or Publication. This Standard does not purport to address all safety problems associated with its use or all applicable regulatory requirements. It is the responsibility of the user of this Standard to establish appropriate safety and health practices and to determine the applicab

6、ility of regulatory limitations before its use. Any use of trademarks in this document are for information purposes and do not constitute an endorsement by TIA or this committee of the products or services of the company. (From Project No. ANSI/TIA-PN-136.337-RF2-WD, formulated under the cognizance

7、of the TIA TR-45 Mobile (b) there is no assurance that the Document will be approved by any Committee of TIA or any other body in its present or any other form; (c) the Document may be amended, modified or changed in the standards development or any editing process. The use or practice of contents o

8、f this Document may involve the use of intellectual property rights (“IPR”), including pending or issued patents, or copyrights, owned by one or more parties. TIA makes no search or investigation for IPR. When IPR consisting of patents and published pending patent applications are claimed and called

9、 to TIAs attention, a statement from the holder thereof is requested, all in accordance with the Manual. TIA takes no position with reference to, and disclaims any obligation to investigate or inquire into, the scope or validity of any claims of IPR. TIA will neither be a party to discussions of any

10、 licensing terms or conditions, which are instead left to the parties involved, nor will TIA opine or judge whether proposed licensing terms or conditions are reasonable or non-discriminatory. TIA does not warrant or represent that procedures or practices suggested or provided in the Manual have bee

11、n complied with as respects the Document or its contents. If the Document contains one or more Normative References to a document published by another organization (“other SSO”) engaged in the formulation, development or publication of standards (whether designated as a standard, specification, reco

12、mmendation or otherwise), whether such reference consists of mandatory, alternate or optional elements (as defined in the TIA Procedures for American National Standards) then (i) TIA disclaims any duty or obligation to search or investigate the records of any other SSO for IPR or letters of assuranc

13、e relating to any such Normative Reference; (ii) TIAs policy of encouragement of voluntary disclosure (see TIA Procedures for American National Standards Annex C.1.2.3) of Essential Patent(s) and published pending patent applications shall apply; and (iii) Information as to claims of IPR in the reco

14、rds or publications of the other SSO shall not constitute identification to TIA of a claim of Essential Patent(s) or published pending patent applications. TIA does not enforce or monitor compliance with the contents of the Document. TIA does not certify, inspect, test or otherwise investigate produ

15、cts, designs or services or any claims of compliance with the contents of the Document. ALL WARRANTIES, EXPRESS OR IMPLIED, ARE DISCLAIMED, INCLUDING WITHOUT LIMITATION, ANY AND ALL WARRANTIES CONCERNING THE ACCURACY OF THE CONTENTS, ITS FITNESS OR APPROPRIATENESS FOR A PARTICULAR PURPOSE OR USE, IT

16、S MERCHANTABILITY AND ITS NONINFRINGEMENT OF ANY THIRD PARTYS INTELLECTUAL PROPERTY RIGHTS. TIA EXPRESSLY DISCLAIMS ANY AND ALL RESPONSIBILITIES FOR THE ACCURACY OF THE CONTENTS AND MAKES NO REPRESENTATIONS OR WARRANTIES REGARDING THE CONTENTS COMPLIANCE WITH ANY APPLICABLE STATUTE, RULE OR REGULATI

17、ON, OR THE SAFETY OR HEALTH EFFECTS OF THE CONTENTS OR ANY PRODUCT OR SERVICE REFERRED TO IN THE DOCUMENT OR PRODUCED OR RENDERED TO COMPLY WITH THE CONTENTS. TIA SHALL NOT BE LIABLE FOR ANY AND ALL DAMAGES, DIRECT OR INDIRECT, ARISING FROM OR RELATING TO ANY USE OF THE CONTENTS CONTAINED HEREIN, IN

18、CLUDING WITHOUT LIMITATION ANY AND ALL INDIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES (INCLUDING DAMAGES FOR LOSS OF BUSINESS, LOSS OF PROFITS, LITIGATION, OR THE LIKE), WHETHER BASED UPON BREACH OF CONTRACT, BREACH OF WARRANTY, TORT (INCLUDING NEGLIGENCE), PRODUCT LIABILITY OR OTHERWISE, EV

19、EN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. THE FOREGOING NEGATION OF DAMAGES IS A FUNDAMENTAL ELEMENT OF THE USE OF THE CONTENTS HEREOF, AND THESE CONTENTS WOULD NOT BE PUBLISHED BY TIA WITHOUT SUCH LIMITATIONS. TIA/EIA-136-337iForeword This foreword is not part of TIA/EIA-136-3371TIA/EIA-136

20、-337 specifies the Gs interface in the GPRS-136 packet-data2architecture.3TIA/EIA-136-337 was developed by TR-45.3.2, the Data Services Working4Group of TR-45.3, the TIA TDMA Wireless Standards Subcommittee.5This document references publications developed by ETSI (European6Telecommunications Standar

21、ds Institute). These referenced publications are7freely available at http:/www.etsi.org.8TIA welcomes suggestions for improvement of this standard. Please send9suggestions to the following address:10Telecommunications Industry Association112500 Wilson Boulevard Suite 30012Arlington VA 22201-38361314

22、151617TIA/EIA-136-337iiTHIS PAGE INTENTIONALLY LEFT BLANKTIA/EIA-136-337iiiContents11. Introduction . 122. Interface Procedures and Messages. 133. Description of the association between an MSC/VLR and an SGSN 243.1 Association at the MSC/VLR . 253.1.1 States at the MSC/VLR 263.2 Association at the S

23、GSN 373.2.1 MM context variables at the SGSN . 383.2.2 States at the SGSN. 394. Tunneling for non-GPRS-136 services 3104.1 General description. 3114.2 Procedures in the MSC/VLR 3124.3 Procedures in the SGSN . 4135. Message Formats and Coding 5145.1 Message Content 5155.1.1 BSSAP+-DOWNLINK-TUNNEL-REQ

24、UEST . 5165.1.2 BSSAP+-UPLINK-TUNNEL-REQUEST. 5175.2 Information element coding 5185.2.1 Downlink Tunnel Payload Control and Info 6195.2.2 Erroneous Message 6205.2.3 Gs Cause value. 6215.2.4 IMSI. 6225.2.5 Information Element Identifiers. 7235.2.6 Message type . 7245.2.7 SGSN number 7255.2.8 Uplink

25、Tunnel Payload Control and Info. 7265.2.9 VLR number 8276. References 928TIA/EIA-136-337ivRevision History1Version DescriptionTIA/EIA-136-337 First releaseTIA/EIA-136-33711. Introduction1The Gs interface connects the MSC/VLR and the SGSN in the GPRS-136 network2architecture (see TIA/EIA-136-330 1).

26、This standard lists the layer-3 procedures and3messages applicable to the Gs interface in a GPRS-136 network. It also describes the4association between an MSC/VLR and an SGSN.52. Interface Procedures and Messages6The following is the list of Gs interface procedures (see GSM 09.18 2) that are7applica

27、ble to the GPRS-136 network:8 Paging for non-GPRS services9 MSC/VLR failure procedure10 SGSN failure procedure11 Error-Handling and Future-Compatibility procedure12In addition to the above procedures, the Tunneling for non-GPRS-136 services procedure13defined in this standard shall apply.14The follo

28、wing is the list of Gs interface messages (see GSM 09.18) that are applicable to15the GPRS-136 network:16 BSSAP+-PAGING-REQUEST17 BSSAP+-PAGING-REJECT18 BSSAP+-RESET-INDICATION19 BSSAP+-RESET-ACK20 BSSAP+-MOBILE-STATUS21 BSSAP+-MS-UNREACHABLE22In addition to the above messages, the following message

29、s defined in this standard shall23apply.24 BSSAP+-UPLINK-TUNNEL-REQUEST25 BSSAP+-DOWNLINK-TUNNEL-REQUEST26TIA/EIA-136-33723. Description of the association between1an MSC/VLR and an SGSN2The following descriptions of the MSC/VLR-SGSN-association shall be used in lieu of3the description in GSM 09.18.

30、43.1 Association at the MSC/VLR5The states associated to the Gs interface in the MSC/VLR are specified in this section.6The state-description does not include message error handling (see GSM 09.18).73.1.1 States at the MSC/VLR8Gs-NULL9 There is no SGSN-association for the MS and therefore the MSC/VL

31、R considers10that the MS is detached of GPRS-136 packet services. In this state, no messages11are sent to an SGSN. Any message other than BSSAP+-UPLINK-TUNNEL-12REQUEST sent from an SGSN shall be ignored. Once the MSC/VLR receives a13BSSAP+-UPLINK-TUNNEL-REQUEST message containing a Registration14fr

32、om the SGSN, the LA-UPDATE PRESENT state is entered.15LA-UPDATE PRESENT16 In this state, the MSC/VLR waits for the outcome of the Registration procedure17from the HLR. The MSC/VLR shall send BSSAP+-PAGING-REQUEST18messages to Class-B136 mobile stations via the Gs interface only. On receiving a19regn

33、ot message, if the registration attempt succeeds, the state of the association20is moved to Gs-ASSOCIATED. If it fails, the state is moved to Gs-NULL. The21state of the association is moved to Gs-NULL also by the receipt of a BSSAP+-22PAGING-REJECT or a BSSAP+-RESET-INDICATION from the SGSN, a23REGC

34、ANC from the HLR, or a Registration message from the MS with a24Powerdown or Deregistration indication.25Gs-ASSOCIATED26 The MSC/VLR considers that the MS is attached to both GPRS-136 and non-27GPRS-136 services. In this state, the MSC/VLR sends BSSAP+-PAGING-28REQUEST messages to Class-B136 mobile

35、stations via the Gs interface only.29The state of the association is moved to Gs-NULL by the receipt of a BSSAP+-30PAGING-REJECT or a BSSAP+-RESET-INDICATION from the SGSN, a31REGCANC from the HLR, or a Registration message from the MS with a32Powerdown or Deregistration indication.33TIA/EIA-136-337

36、33.2 Association at the SGSN1The states and MM context variables associated to the Gs interface in the SGSN are2specified in this section. The state-description does not include message error handling3(see GSM 09.18).43.2.1 MM context variables at the SGSN5See GSM 09.18.63.2.2 States at the SGSN7Gs-

37、NULL8 There is no association to a MSC/VLR stored for the MS, and therefore the9SGSN shall consider that the MS is detached for non-GPRS-136 services. In this10state, the SGSN shall accept BSSAP+-PAGING-REQUEST messages to mobile11stations only if the SGSN-Reset restoration indicator in the SGSN is

38、set to12true (see GSM 09.18). The state of the association shall be moved to Gs-13ASSOCIATED upon receiving a message from the MS on one of the LLC layer14tunneling SAPs containing signaling messages (see TIA/EIA-136-330).15Gs-ASSOCIATED16 The SGSN shall store an association for the MS. In this stat

39、e, the SGSN shall17perform tunneling of signaling messages between the MSC/VLR and the MS.18The state of the association is moved to Gs-NULL due to an explicit or implicit19Detach, receipt of a BSSAP+-RESET-INDICATION from the MSC/VLR, or on20receiving an SGSN-Context-Request (see GSM 03.60 3) for t

40、he MS.214. Tunneling for non-GPRS-136 services224.1 General description23This procedure shall be used to tunnel TIA/EIA-136 specific messages between the MS24and the MSC/VLR. The SGSN provides just a transport service for the messages to be25tunneled and shall not interpret the tunneling payload.264

41、.2 Procedures in the MSC/VLR27When the MSC/VLR has a message to be tunneled to the MS, whose Gs state is not Gs-28NULL, it shall send a BSSAP+-DOWNLINK-TUNNEL-REQUEST message to the29SGSN associated with the MS. The Cipher Request field E shall be set to 1 if LLC layer30ciphering is desired. The pri

42、ority level for the payload shall be set as below:31TIA/EIA-136-3374Payload Type TunnelPriorityAll TIA/EIA-136 messages except R-DATA, R-DATA ACCEPT, andR-DATA REJECT00All R-DATA, R-DATA ACCEPT, R-DATA REJECT messages 10All other values of Tunnel Priority are reserved1The action taken by the MSC/VLR

43、 on receiving a BSSAP+-UPLINK-TUNNEL-2REQUEST message shall depend on the contents of the Message Capsule received in the3Tunnel Payload field.44.3 Procedures in the SGSN5A message received by the SGSN from an MS or sent by the SGSN to the MS on one of6the Tunneling of Messages (TOM) LLC SAPs is cal

44、led a TOM Protocol Envelope (see7TIA/EIA-136-336). The TOM Protocol Envelope is composed of the TOM Protocol8Header immediately followed by a Message Capsule.9Upon receipt of a TOM Protocol Envelope with a TOM Protocol Header indicating the10presence of one or more TIA/EIA-136 messages, the SGSN sha

45、ll determine the11MSC/VLR to which the Message Capsule in the TOM Protocol Envelope shall be12forwarded. The SGSN shall make this determination based upon the RAI of the MS, the13TOM Protocol Discriminator field in the TOM Protocol Header, and TIA/EIA-13614specific information in the remaining octet

46、s (if any) in the TOM Protocol Header (see15TIA/EIA-136-336). The SGSN shall then forward a BSSAP+-UPLINK-TUNNEL-16REQUEST message to the selected MSC/VLR with the received Message Capsule in the17Tunnel Payload field. The Protocol Discriminator field in the BSSAP+-UPLINK-18TUNNEL-REQUEST message sh

47、all be set to TIA/EIA-136. Tunnel Priority field in the19BSSAP+-UPLINK-TUNNEL-REQUEST message shall be set based on the LLC SAP on20which the TOM Protocol Envelope was received. The Cipher Mode field E shall be set to211 if the TOM Protocol Envelope was received by the LLC in ciphered form, otherwis

48、e it22shall be set to 0. Gs state shall be set to Gs-ASSOCIATED if it is not Gs-ASSOCIATED23already.24Upon receipt of a BSSAP+-DOWNLINK-TUNNEL-REQUEST message from an25MSC/VLR, the SGSN shall construct a TOM Protocol Envelope by mapping the Tunnel26Payload field to the Message Capsule portion of the

49、 TOM Protocol Envelope. The TOM27Protocol Header shall be set to TIA/EIA-136. The SGSN shall then send the TOM28Protocol Envelope to the MS on a specific LLC SAP. This LLC SAP shall be determined29by the Tunnel Priority field in the BSSAP+-DOWNLINK-TUNNEL-REQUEST30message. LLC ciphering shall be enabled or disabled based upon the value of the Cipher31Request field E in this message. If the SGSN is unable to send the TOM Protocol32Envelope to the indicated MS for any reason (including the inability to accommodate the33ciphering request as indicated in the