Doc Code: TR.PROV
`
`
`
`Document Description: Provisional Cover Sheet (SB16)
`
`PTOISB/16 (04--07)
`Approved for use lhrough 06/30/2010 0MB 0651-0032
`
`
`U.S. Patent and Trademark Office: U.S. DEPARTMENT OF COMMERCE
`
`
`
`
`Under the Paperwork Reduction Act of 1995, no persons are required to respond to a collection of information unless it displays a valid 0MB control number
`
`
`
`Provisional Application for Patent Cover Sheet
`
`
`
`
`
`
`This is a request for filing a PROVISIONAL APPLICATION FOR PATENT under 37 CFR 1.53(c)
`
`lnventor(s)
`
`
`
`Inventor 1
`
`Given Name
`
`Middle Name Family Name City
`
`State
`
`I Remove I
`Country i
`
`Joon
`
`Bae
`
`Kim
`
`Lexington
`MA
`
`us
`
`Inventor 2
`
`Given Name
`
`Middle Name Family Name
`
`City State
`
`I Remove I
`Country i
`
`Marcos
`
`Tzannes
`
`Orinda CA
`
`us
`
`All Inventors Must Be Listed -Additional Inventor Information blocks may be
`
`
`
`
`
`
`generated within this form by selecting the Add button.
`
`I I
`Add
`
`Title of Invention
`
`
`
`Header Repetition Scheme in Packet-based OFDM Systems
`
`
`
`
`
`Attorney Docket Number (if applicable)
`5550-87-PROV
`
`
`
`Correspondence Address
`
`
`
`Direct all correspondence to (select one):
`
`@ The address corresponding
`
`
`to Customer Number 0 Firm or Individual Name
`
`Customer Number
`
`62574
`
`The invention was made by an agency of the United States Government or under a contract with an agency of the United
`
`
`
`States Government.
`
`@ No.
`
`
`contract number are: 0 Yes, the name of the U.S. Government agency and the Government
`
`
`
`
`
`EFS -Web 1.0.1
`
`INTEL-1009
`10,079,707
`
`

`

`Doc Code: TR.PROV
`Document Description: Provisional Cover Sheet (SB16)
`
`PTO/SB/16 (04-07)
`Approved for use through 06/30/2010 0MB 0651-0032
`U.S. Patent and Trademark Office: U.S. DEPARTMENT OF COMMERCE
`Under the Paperwork Reduction Act of 1995, no persons are required to respond to a collection of information unless it displays a valid 0MB control number
`
`Entity Status
`Applicant claims small entity status under 37 CFR 1.27
`0 Yes, applicant qualifies for small entity status under 37 CFR 1.27
`® No
`Warning
`
`Petitioner/applicant is cautioned to avoid submitting personal information in documents filed in a patent application that may
`contribute to identity theft. Personal information such as social security numbers, bank account numbers, or credit card
`numbers (other than a check or credit card authorization form PT0-2038 submitted for payment purposes) is never required
`by the USPTO to support a petition or an application. If this type of personal information is included in documents submitted
`to the USPTO, petitioners/applicants should consider redacting such personal information from the documents before
`submitting them to USPTO. Petitioner/applicant is advised that the record of a patent application is available to the public
`after publication of the application (unless a non-publication request in compliance with 37 CFR 1.213(a) is made in the
`application) or issuance of a patent. Furthermore, the record from an abandoned application may also be available to the
`public if the application is referenced in a published application or an issued patent (see 37 CFR1 .14). Checks and credit
`card authorization forms PT0-2038 submitted for payment purposes are not retained in the application file and therefore are
`not publicly available.
`
`Signature
`
`Please see 37 CFR 1.4(d} for the form of the signature.
`
`Signature
`
`/Jason H. Vick/
`
`Date (YYYY-MM-DD)
`
`2009-08-21
`
`First Name
`
`Jason H.
`
`Last Name
`
`Vick
`
`Registration Number
`(If appropriate)
`
`45285
`
`This collection of information is required by 37 CFR 1.51. The information is required to obtain or retain a benefit by the public which is to
`file (and by the USPTO to process) an application. Confidentiality is governed by 35 U.S.C. 122 and 37 CFR 1.11 and 1.14. This collection
`is estimated to take 8 hours to complete, including gathering, preparing, and submitting the completed application form to the USPTO.
`Time will vary depending upon the individual case. Any comments on the amount of time you require to complete this form and/or
`suggestions for reducing this burden, should be sent to the Chief Information Officer, U.S. Patent and Trademark Office, U.S. Department
`of Commerce, P.O. Box 1450, Alexandria, VA 22313-1450. DO NOT SEND FEES OR COMPLETED FORMS TO THIS ADDRESS. This
`form can only be used when in conjunction with EFS-Web. If this form is mailed to the USPTO, it may cause delays in handling
`the provisional application.
`
`EFS - Web 1.0.1
`
`

`

`Privacy Act Statement
`
`The Privacy Act of 1974 (P.L. 93-579) requires that you be given certain information in connection with your submission of
`the attached form related to a patent application or paten. Accordingly, pursuant to the requirements of the Act, please be
`advised that : (1) the general authority for the collection of this information is 35 U.S.C. 2(b)(2); (2) furnishing of the
`information solicited is voluntary; and (3) the principal purpose for which the information is used by the U.S. Patent and
`Trademark Office is to process and/or examine your submission related to a patent application or patent. If you do not
`furnish the requested information, the U.S. Patent and Trademark Office may not be able to process and/or examine your
`submission, which may result in termination of proceedings or abandonment of the application or expiration of the patent.
`
`The information provided by you in this form will be subject to the following routine uses:
`
`1.
`
`2.
`
`3.
`
`4.
`
`5.
`
`6.
`
`7.
`
`8.
`
`9.
`
`The information on this form will be treated confidentially to the extent allowed under the Freedom of Information
`Act (5 U.S.C. 552) and the Privacy Act (5 U.S.C 552a). Records from this system of records may be disclosed to the
`Department of Justice to determine whether disclosure of these records is required by the Freedom of Information
`Act.
`A record from this system of records may be disclosed, as a routine use, in the course of presenting evidence to
`a court, magistrate, or administrative tribunal, including disclosures to opposing counsel in the course of settlement
`negotiations.
`A record in this system of records may be disclosed, as a routine use, to a Member of Congress submitting a
`request involving an individual, to whom the record pertains, when the individual has requested assistance from the
`Member with respect to the subject matter of the record.
`A record in this system of records may be disclosed, as a routine use, to a contractor of the Agency having need
`for the information in order to perform a contract. Recipients of information shall be required to comply with the
`requirements of the Privacy Act of 1974, as amended, pursuant to 5 U.S.C. 552a(m).
`A record related to an International Application filed under the Patent Cooperation Treaty in this system of
`records may be disclosed, as a routine use, to the International Bureau of the World Intellectual Property
`Organization, pursuant to the Patent Cooperation Treaty.
`A record in this system of records may be disclosed, as a routine use, to a n other federal agency for purposes
`of National Security review (35 U.S.C. 181) and for review pursuant to the Atomic Energy Act (42 U.S.C. 218(c)).
`A record from this system of records may be disclosed, as a routine use, to the Administrator, General Services,
`or his/her designee, during an inspection of records conducted by GSA as part of that agency's responsibility to
`recommend improvements in records management practices and programs, under authority of 44 U.S.C. 2904 and
`2906. Such disclosure shall be made in accordance with the GSA regulations governing inspection of records for this
`purpose, and any other relevant (i.e., GSA or Commerce) directive. Such disclosure shall not be used to make
`determinations about individuals.
`A record from this system of records may be disclosed, as a routine use, to the public after either publication of
`the application pursuant to 35 U.S.C. 122(b) or issuance of a patent pursuant to 35 U.S.C. 151. Further, a record
`may be disclosed, subject to the limitations of 37 CFR 1.14, as a routine use, to the public if the record was filed in an
`application which became abandoned or in which the proceedings were terminated and which application is
`referenced by either a published application, an application open to public inspection or an
`issued patent.
`A record from this system of records may be disclosed, as a routine use, to a Federal, State, or local law
`enforcement agency, if the USPTO becomes aware of a violation or potential violation of law or regulation.
`
`

`

`Atty. Docket No.: 5550-87-PROV
`
`1 PROVISIONAL PATENT APPLICATION
`
`Header Repetition Scheme in Packet-based OFDM Systems
`
`2
`
`INVENTORS
`
`Joon Bae Kim
`Marcos Tzannes
`
`3 BRIEF OVERVIEW OF AN EXEMPLARY EMBODIMENT OF THE INVENTION
`
`This invention describes methods to facilitate nodes (devices) using different repetition schemes for
`their header transmission to communicate with one another in a single domain (network) in the
`presence of nodes operating on partial bandwidth (e.g., reduced sampling rate).
`
`4 BACKGROUND
`
`Conventional multi-user communication systems use frame-based (or packet-based) transmission to
`communicate between two or more users over a shared channel based on OFDM. A packet is usually
`formed by preamble, header, and payload, and transmitted using time-sharing or contention-based
`media access methods. The example of such system includes IEEE 802.11 (Wireless LAN), IEEE
`802.16 (WiMAX), and ITU G.9960 (G.hn). These systems use OFDM transmission (also referred to
`sometimes as Discrete Multi-Tone (DMT)) which divides the transmission frequency band into
`multiple subcarriers (also referred to as tones or sub-channels), with each sub-carrier individually
`modulating a bit or a collection of bits.
`
`The header contains important control information for the receiver to decode the payload properly, and
`also provides information about the packet length for virtual carrier sensing. Hence it is essential to
`decode the header reliably. In G.9960 the header containing PHY H bits (header information block) is
`carried over one or two OFDM symbols (D = 1 or 2), and within each symbol, multiple header
`information blocks are repeated over the entire frequency band [1]. The default value of Dis 1, but
`expanding it to 2 in some cases is under discussion [2, 3]. The possibility of carrying more than PHY H
`bits in the header (H = 1 or 2) is also under discussion [2, 4].
`
`5 TECHNICAL DESCRIPTION OF THE INVENTION
`
`What has not been discussed is allowing different values of D in a single domain where nodes are
`operating in different portions of frequency bands. For the power-line medium, G.9960 has defined
`two overlapped baseband bandplans, 50MHz-PB and lO0MHz-PB. The possibility of having narrower
`bandplans such as 25MHz-PB and 12.5MHz-PB are under discussion in order to support SmartGrid
`applications. In this scenario, the level of frequency diversity is different depending on the bandplan,
`hence provides different header decodibility if D is fixed to 1. If D is fixed to 2, then it increases
`
`

`

`Atty. Docket No.: 5550-87-PROV
`reliability for the narrow band devices, but unnecessarily increases overhead for the wide-band
`devices.
`
`This invention describes methods to accommodate different repetition schemes (D = I, ... , DMAX and
`H = I, ... , HMAX) in a single domain, and still allow devices to communicate with one another. DMAX
`and HMAX can be larger than 2.
`
`5.1 Example of header repetition when D, H = 1 or 2
`
`Figure 1 describes the header repetition scheme when D, H = 1 or 2.
`
`(1) PHY-frame header (H = 1 & D = 1)
`
`n
`
`__ ,,
`
`Payload
`
`(2) PHY-frame header (H = 1 & D = 2)
`
`(3) PHY-frame header (H = 2 & D = 1)
`
`Payload
`
`Header
`
`Payload
`
`(4) PHY-frame header (H = 2 & D = 2)
`
`Header
`
`Payload
`
`Figure 1: Header repetition scheme (D, H = 1 or 2)
`
`The shaded block represents the copy of the unshaded block with the same label. The modulation of
`the copied block may not be exactly the same as its original version. The label "Header Ext"
`emphasizes the fact that it contains different header information than "Header". The payload after the
`header may be omitted in some cases ( e.g., ACK, RTS/CTS). The repetition scheme expands similarly
`with larger values of DMAX and HMAX• The invention focuses on dealing with different values of D.
`Different values of H can be supported in straightforward way as proposed in [2].
`
`5.2 Detection by receiver (variable repetition)
`
`In this exemplary embodiment, the transmitter selects ( or determines) at least one D value. This
`selection may be at its own discretion, or based on information communicated between one or more
`receivers, or based on instruction from one or more receivers. Selection may depend on the number of
`available sub-carriers ( or the bandwidth) of the bandplan the transmitter operates on and/or the
`receiver(s) operates on. In this exemplary embodiment a receiving node in the domain should be able
`to decode packets sent by the transmitter without knowing D a priori (i.e. prior to decoding the packet
`header).
`
`One exemplary method is for a transmitter to carry the value of D in the header so that all nodes know
`how many OFDM symbols are carrying header information. The receiver starts processing the header
`
`2
`
`

`

`Atty. Docket No.: 5550-87-PROV
`by decoding one OFDM header symbol. If the receiver decodes it successfully, then it knows how
`many more OFDM symbols (D-1) carrying header information for a given frame. If the receiver fails
`to obtain header information out of one OFDM header symbol (i.e. the header decoding fails), then it
`can try to decode two OFDM header symbols, and so on. The decoding of each additional OFDM
`header symbol provides additional diversity thereby increasing the likelihood of decoding the header
`information correctly.
`
`5.3 Fixed repetition scheme per domain
`
`In one exemplary embodiment, the domain master selects ( or determines) one or more fixed D values
`for at least one node in the domain. For example, the domain master may select one fixed value for all
`nodes in a domain. Selection may depend on the number of available sub-carriers ( or the bandwidth) of
`the bandplans that the domain members operate on. The domain master may change the value of D
`dynamically. A node in the domain first needs to determine the D that the domain master has set ( or
`selected/ determined).
`
`One exemplary method is for the domain master to carry the selected value of D in the header of the
`MAP frame while also using this D value for the transmission of the MAP header ( as described in
`§5.1). In this case, a node will determine out this D value using the methods described in §5.1. After
`this value is determined by a node, the node will use this value until it is changed by the domain
`master.
`
`Other exemplary method is for the domain master to carry the selected value of D in the MAP and
`while using a fixed D for the header of the MAP frame ( e.g., pre-defined per medium or DMAX), The D
`value in the MAP will be used for non-MAP frames/packets. In this case a node in the domain does not
`need multiple levels of header decode process (as described in §5.1). Also in this exemplary method,
`the MAP may be sent with a different D value than the D value used for other (non-MAP)
`frames/packets.
`
`5.4 Fixed repetition scheme per TXOP
`
`Additionally or alternately, the domain master may select ( or determine) a D value per TXOP. This
`selection may be at its own discretion, or based on information communicated between one or more
`receivers, or based on instruction from one or more receivers. Selection may depend on the number of
`available sub-carriers ( or the bandwidth) of the bandplan the transmitter operates on and/or the
`receiver( s) operates on.
`One exemplary method is to include D in the TXOP descriptor transmitted in the MAP so that all
`nodes know in advance what values of Dis used for that TXOP. TXOP descriptor is the part of the
`MAP message which can be communicated via the MAP frame as described in §5.2.
`
`6 GENERAL TERMS
`The terms subcarrier, subchannel and tone have the same meaning and are used interchangeably in the
`description.
`The terms receiver, receiving node and receiving transceiver have the same meaning and are used
`interchangeably in the description.
`
`3
`
`

`

`Atty. Docket No.: 5550-87-PROV
`The term transmitter, transmitting node and transmitting transceiver have the same meaning and are
`used interchangeably in the description.
`
`The terms transceiver and modem have the same meaning and are used interchangeably in the
`description.
`The term frame and packet have the same meaning and are used interchangeably in the description.
`The term header and PHY-frame header have the same meaning and are used interchangeably in the
`description.
`The terms network and home network have the same meaning and are used interchangeably in the
`description. While the term Home network has been used in this description, the description is not
`limited to home networks but in fact applies also to any network, such as enterprise networks, business
`networks, or any network with a plurality of connected nodes.
`
`The above-described methods and systems and can be implemented in a software module, a software
`and/or hardware testing module, a telecommunications test device, a DSL modem, an ADSL modem,
`an xDSL modem, a VDSL modem, a linecard, a G.hn transceiver, a MOCA transceiver, a Homeplug
`transceiver, a powerline modem, a wired, a wireless modem such as 802.1 la/g/n or 802.16, test
`equipment, a multicarrier transceiver, a wired and/or wireless wide/local area network system, a
`satellite communication system, network-based communication systems, such as an IP, Ethernet or
`ATM system, a modem equipped with diagnostic capabilities, or the like, or on a separate programmed
`general purpose computer having a communications device or in conjunction with any of the following
`communications protocols: CDSL, ADSL2, ADSL2+, VDSLI, VDSL2, HDSL, DSL Lite, IDSL,
`RADSL, SDSL, UDSL, MOCA, G.hn, Homeplug or the like.
`
`Additionally, the systems, methods and protocols of this invention can be implemented on a special
`purpose computer, a programmed microprocessor or microcontroller and peripheral integrated circuit
`element(s), an ASIC or other integrated circuit, a digital signal processor, a flashable device, a hard(cid:173)
`wired electronic or logic circuit such as discrete element circuit, a programmable logic device such as
`PLD, PLA, FPGA, PAL, a modem, a transmitter/receiver, any comparable means, or the like. In
`general, any device capable of implementing a state machine that is in tum capable of implementing
`the methodology illustrated herein can be used to implement the various communication methods,
`protocols and techniques according to this invention. While the systems and means disclosed herein
`are described in relation to various functions that are performed, it is to be appreciated that the systems
`and means may not always perform all of the various functions, but are capable of performing one or
`more of the disclosed functions.
`
`Furthermore, the disclosed methods may be readily implemented in software using object or object(cid:173)
`oriented software development environments that provide portable source code that can be used on a
`variety of computer or workstation platforms. Alternatively, the disclosed system may be implemented
`partially or fully in hardware using standard logic circuits or VLSI design. Whether software or
`hardware is used to implement the systems in accordance with this invention is dependent on the speed
`and/or efficiency requirements of the system, the particular function, and the particular software or
`hardware systems or microprocessor or microcomputer systems being utilized. The communication
`systems, methods and protocols illustrated herein can be readily implemented in hardware and/or
`software using any known or later developed systems or structures, devices and/or software by those of
`ordinary skill in the applicable art from the functional description provided herein and with a general
`basic knowledge of the computer and telecommunications arts.
`
`4
`
`

`

`Atty. Docket No.: 5550-87-PROV
`Moreover, the disclosed methods may be readily implemented in software that can be stored on a
`computer-readable storage medium, executed on programmed general-purpose computer with the
`cooperation of a controller and memory, a special purpose computer, a microprocessor, or the like. In
`these instances, the systems and methods of this invention can be implemented as program embedded
`on personal computer such as an applet, JAVA® or CGI script, as a resource residing on a server or
`computer workstation, as a routine embedded in a dedicated communication system or system
`component, or the like. The system can also be implemented by physically incorporating the system
`and/or method into a software and/or hardware system, such as the hardware and software systems of a
`test/modeling device.
`While the invention is described in terms of exemplary embodiments, it should be appreciated that
`individual aspects of the invention could be separately claimed and one or more of the features of the
`various embodiments can be combined.
`
`While the systems and means disclosed herein are described in relation to various functions that are
`performed, it is to be appreciated that the systems and means may not always perform all of the various
`functions, but are capable of performing one or more of the disclosed functions.
`While the exemplary embodiments illustrated herein discuss the various components collocated, it is to
`be appreciated that the various components of the system can be located a distant portions of a
`distributed network, such as a telecommunications network and/or the Internet or within a dedicated
`communications network. Thus, it should be appreciated that the components of the system can be
`combined into one or more devices or collocated on a particular node of a distributed network, such as
`a telecommunications network. As will be appreciated from the following description, and for reasons
`of computational efficiency, the components of the communications network can be arranged at any
`location within the distributed network without affecting the operation of the system.
`
`It is therefore apparent that there has been provided, in accordance with the present invention, systems
`and methods for detecting unfiltered device(s). While this invention has been described in conjunction
`with a number of embodiments, it is evident that many alternatives, modifications and variations
`would be or are apparent to those of ordinary skill in the applicable arts. Accordingly, it is intended to
`embrace all such alternatives, modifications, equivalents and variations that are within the spirit and
`scope of this invention.
`
`7 CLAIMS
`1.
`A method for allowing different values of D in a single domain where nodes are operating
`in different portions of frequency bands.
`A method to accommodate different repetition schemes (D = 1, ... , DMAX and H = l,
`2.
`... , HMAX) in a single domain, and still allow devices to communicate with one another. DMAX and
`HMAX can be larger than 2.
`
`8 REFERENCE
`
`[1] Editor for G.9960, "ITU-T Recommendation G.9960: Next generation wire-line based home
`networking transceivers - Foundation," ITU-T SGJ 5/Q4, Jan. 2009.
`
`[2] Aware, "G.hn: PHY-Frame Header Extension," ITU-T SG15/Q4 09CC-046, Concord, California,
`Aug. 2009.
`
`5
`
`

`

`Atty. Docket No.: 5550-87-PROV
`
`[3] CopperGate, "G.hn: Using Two Symbols for the Header of a PHY frame on Coax," ITU-T
`SG15/Q4 09XC-100, Xian, China, Jul. 2009.
`
`[4]
`
`Intellon, "G.hn: Extended PHY frame header," ITU-T SGJ 5/Q4 09XC-l 19, Xian, China, Jul.
`2009.
`
`6
`
`

`

`ITU - Telecommunication Standardization Sector
`
`Temporary Document 09CC-046
`
`STUDY GROUP 15
`
`Original: English
`
`Concord, California, 24 - 28 August 2009
`
`Question: 4/15
`
`SOURCE 1
`
`: Aware
`
`TITLE:
`
`G.hn: PHY-Frame Header Extension
`
`ABSTRACT
`
`This contribution proposes a generic PHY-frame header extension scheme to incorporate larger
`than PHY H bits in the header (Issue 5.0.1.2.1.0.13). It also proposes not to fix the number of header
`repetitions (D) unconditionally for any given medium since the wide range ofbandplans shall be
`accommodated effectively in a single domain (Issue 5.0.1.2.1.2.0.1).
`
`I Introduction I Proposal I Text Update I Summary I
`
`1 Contact:
`
`Joan Bae Kim
`Aware, Inc.
`
`T: +1 781 276 4000
`E: ibkim(a>aware.com
`
`1
`
`

`

`1
`
`Introduction
`
`The group has been discussing PHY-frame header extension in two different aspects, (1) increasing
`the number of information bits carried in the PHY-frame header, and (2) repeating the same header
`information over two OFDM symbols for enhanced diversity combination. We need to have a
`generic and consistent approach to accomplish these two goals.
`
`In 09CV meeting the group agreed to specify a scheme to extend the PHY-frame header so that
`larger than PHYH bits can be accommodated in the PHY-frame header (Issue 5.0.1.2.1.0.13). This
`contribution proposes a generic scheme to extend the PHY-frame header. The proposed scheme
`makes G.hn future-proof, and it can be immediately used to support bi-directional transmission
`proposed by [ 4].
`
`Item Number
`
`Status
`
`Item Description
`
`5.0.1.2.1.0.13
`
`Agreed
`8-Apr-09
`
`That G .hn shall specify means to extend the PHY -frame
`header.
`
`Reference(s)
`
`09CV-042
`
`In 09XC meeting the group provisionally agreed that the number of PHY-frame header repetitions
`(D) shall be set to 2 in the coax medium since the number of available sub-carriers in coax 50MHz
`bandplan (256) is not enough to guarantee the reliability of PHY-frame header (Issue
`5.0.1.2.1.2.0.1 ).
`
`Item Number
`
`Status
`
`Item Description
`
`5.0.1.2.1.2.0.1
`
`Provisionally, that the value ofD shall be 2 for the coax
`Agreed
`30-July-09 medium (baseband and RF) subject to there not being any
`alternative proposal submitted by the upload deadline for
`the Q4/15 G.hn meeting August 2009.
`
`Reference(s)
`
`09XC-100
`
`2
`
`

`

`2
`
`Proposal
`
`For extending the capability of carrying more than PHYH bits in the PHY-frame header, we propose
`the followings:
`
`□ Add a bit (Extended Header Indication: EHI) in the original PHY-frame header fields (Table 7-
`1) to indicate whether or not the header extension is applied.
`
`□ Define a generic field description for the extended part of the header in §7.1.2.3.3 (new section),
`which is also PHYH bits long, and contains the common part (e.g., E_HCS) and variable part
`(e.g., E_FTSF).
`
`The text update is proposed in the following section.
`
`For specifying the number of PHY-frame header repetitions (D), we propose not to fix D per
`medium, rather to define a technique to use different values of D. Although it is understood that
`more repetitions may be necessary in coax, fixing D unconditionally for any given medium is
`neither a flexible nor an efficient solution because
`
`□ Even in the power line medium we may face the similar situation as narrower bandplans are
`added to support SmartGrid applications (Issue 1.90.10.1 ). In this case we need a flexible
`scheme to support narrow and wide bandplans at the same time.
`
`Item Number
`
`Status
`
`Item Description
`
`1.90.10.1
`
`Agreed
`
`31-July-09 .
`.
`
`That G.hn shall specify:
`Extensions to support the Smart Grid applications
`A profile that is applicable to Smart Grid for
`devices that need to satisfy the requirements in terms of
`data rate, QoS, power consumption and device complexity.
`
`Reference(s)
`
`09CX-104
`
`□ Applying D = 2 uniformly for all bandplans in coax makes G.hn less efficient for wide
`bandplans (e.g., 200MHz-CRF) as well as over the legacy system.
`
`The possible cases of PHY-frame header transmissions are shown in the following figure.
`
`(1) PHY-frame header without extension & D = 1
`
`Header
`
`Payload
`
`(2) PHY-frame header without extension & D = 2
`
`Payload
`
`Header -
`
`(3) PHY-frame header with extension & D = 1
`
`Header
`
`Payload
`
`(4) PHY-frame header with extension & D = 2
`
`Header
`
`Payload
`
`3
`
`

`

`3
`
`Text Update
`
`3.1
`
`Existing text update for G.9960 Amendment 1
`
`Text is updated based on [3] with all changes accepted.
`
`<Start of text>
`
`7.1.2.3
`
`PHY-frame header
`
`The core nart oftbe PHY-frame header is PHYH bits long and is composed of a common part and a
`variable part. The common part contains fields that are common for all PHY-frame types. The
`variable part contains fields according to the PHY-frame type. PHY-frame type is indicated by the
`FT field. The PAD fields fit the length of the header of different PHY frame-types to the standard
`values of PHY H bits. The content of the h-w,~~:k=w--con'. part _is protected by the 16-bit header check
`sequence (HCS).
`
`The fields of the core part of foe PHY-frame header are defined in Table 7-1.,
`I)et1encUn~~ on the fra_n1e t\-'q:::-;~ the -Pl-f"'_{- -•f:rarnt; bt;i:tder rnav be ex1\;11ded to 2 x PJ-1 Y-_u_ bits lont~. If the
`exttnded header indjcation (fJ-1I) bit is stt U-_H:.:n additiona~ Prr:(~~~ jnfi)r.n1ation bjts of tht txtended
`nart of the r~i-rr..- -frariH.~ h(~ader art attnendtd at the e11d of the core nari of the PI-r1 .. --•frarne header.
`-·rhe ex tE.:nded _part of th(~ _Pl-f'{ .,fra1llE.: hE.:ad(~r sba.!1 be encoded exactl·v fhe s:1rne vva,/ as the core part
`as descr.ihed. in §7.1.3.4.
`
`4
`
`

`

`Table 7-1/G.9960-Con~ part of PHY-frame header fields
`
`Field
`
`Octet
`
`Field
`Size
`[Bits]
`
`FT
`
`DOD
`
`SID
`
`DID
`
`MI
`
`PHI
`
`_Eli1
`
`Reserved
`
`0
`
`0
`
`1
`
`2
`
`3
`
`3
`
`-,
`-~-
`3
`
`Duration
`
`4-5
`
`...
`
`6-18
`
`4
`
`4
`
`8
`
`8
`
`1
`
`1
`
`1
`l
`
`;?~{~
`16
`
`Description
`
`Frame type
`
`Domain ID
`
`The device ID of the source node
`
`The device ID of the destination
`node(s)
`
`Multicast indication identifies
`whether the DID is a multicast
`destination
`
`Post header indication identifies
`whether the first payload symbol
`after the header is a PRBS symbol or
`a data symbol
`
`_Extcnded_ header_JndlcatJon.
`
`Reserved by ITU-T
`
`The PHY frame transmission
`duration
`
`Common part
`
`Variable part
`
`HCS
`
`19-20
`
`16
`
`Header check sequence
`
`Common part
`
`<End of text>
`
`3.2
`
`New text for G.9960 Amendment 1
`
`Text is added based on [3] with all changes accepted.
`
`<Start of text>
`
`7.1.2.3.1.6
`
`Post Header Indication (PHI)
`
`The PHI bit, when set, shall indicate that the first payload symbol following the header is a PRBS
`symbol. Otherwise the first payload symbol shall be a data symbol.
`
`'I'he f:J:{l field~ \:vhen set~ shaH i11djcatt; that the r~1-1 Y frr:trne header contains 2xJlJ:t\·-H inforrnation
`'T'he additio11al PI-f'(p inft-.:rrnatio11 bits of iht extendtd oart of th(~ r~I-I\'.-.-._fiar_ne header are
`b!1~
`--
`.§_necjfied in ~7.1,.2.3,3. If the .E.I-II ~field is zero. then the .Pif1'.~--fra_n1e header shr::Jl contajn PJf':{H
`inforn1aUon bJts. ··rht f~1-ll field shall bt set accordin~:· to the fra1ne tvn(~.
`
`5
`
`

`

`<End of text>
`
`<Start of text>
`
`'T'he extend.ed t1art of the _Pf-I'/ --fra1r1e header js PJ-1 l u btts lonr.:~ and is con1nosed ot a cor11111on oart
`;:Hui ::1 ~/ar1able naxt. 'The corn_n1011 nart cc:ntains _Gelds that are co1nrnon f()r all I-'1-f\{--franH.: tvnes. ··rhE.:
`
`ditt~;rent J?J-'1~-( t}·an1e-t\J)es to the stfanclard ,.tahJ~:s of I~fl\yu bits, 'T'bt; co11tent of the extended DD.rt is
`J)fotected bv the 16-l,it ht(HJE.~r check seQuE.~nce (I~ l!(~S\:.
`
`·rhe [ields of the extended nart of the _Pifl'.~ --fra_n1e header i":tre defined u1 'Table 7--X y-_
`
`Sjze
`f1~i]ts1
`
`152
`
`19--20
`
`-·rh1s_is_ for_further_stud'.?,_
`
`\l:1riabje_part
`
`c:or_n_n1on. oart
`
`I:~ 1-i\..-~-.-: t~ ~1 16--bn C';Jctic redund.anc\' check~ { (~1~(~) and ~h:.tH be con1n1Jted ::.-rv-er an the fields of the
`I~ F'-rSF in the ord(~r tlH~\.,. are iransrnitted, startjn~2- \~/.!th the t .. SI3 c:f' the first field and (:nd_hu~~ v,.rith
`1:· -rsi. --_rhe Si":trne nolvnornial dt;scrjbed in ~ 7 .1.2 .3.1 ,.8 shaH be used.
`the Cv'fSl3 of the last t1ehl ot l:~.
`
`<End of text>
`
`4
`
`[1]
`
`[2]
`
`[3]
`
`References
`
`Editor for G.hn, "G.hn: Draft Text for G.hn -version 4.1," ITU-T SGI 5/Q4 09CC-RI 2,
`Concord, California, Aug. 2009.
`
`Editor for G.hn, "G.hn: Updated Issues List for G.hn," ITU-T SG15/Q4 09XC-U12RI, Xian,
`China, Jul. 2009.
`
`Editor for G.hn, "ITU-T Recommendation G.9960 Unified high-speed wire-line based home
`networking transceivers - Foundation," ITU-T SG 15/Q4 G.9960 LC comment resolution
`draft text R8, Concord, California, Aug. 2009.